When reading data from UART, fetching data is not correct

[StreuB1]

Switch Case is what I was thinking initially as well, @Steve Shannon

That is what that function was designed for, in part. Multi-level branches, like excessively nested if statements.

 

[Steve Shannon]

Switch Case is what I was thinking initially as well, @Steve Shannon

That is what that function was designed for, in part. Multi-level branches, like excessively nested if statements.

Exactly! Far easier to read and maintain. I thought it was a reasonable question when he said he always tried to avoid too many if/elses.

 

[jderimig]

Oh that's actually is so useful. Thanks for teaching me that.

Yes don't implement packet checking and sync until you have exhausted the XBee functions for that. You shouldn't need to write your own when Digi's will be better . The XBee pro only has 2 rf data rates. Slow and best link budget when your uart data rates is 9600 baud or less. Going slower than 9600 doesn't increase your link budget.

 

[waltr]

Oh thank you so much waltr. I would love to come and see. It is like 1.5 hours driving. It's nothing for me. But i won't be able to launch anything yet. I will be coming for learning and meeting with you and some people who has experience. I think i need a push to launch my first and then after my first crash, i will be relaxed Because right now i am trying so much to make it perfect as if i really can do it in my first time. It would be great for me to experience something like that.

We would love having you to a launch. We always need additional help searching and recovering rockets.

I do recommend building a simple kit to learn with. Our next launch is 25 Feb so you do have time to buy and build an Estes Alpha or similar. We also have a vendor at the launch selling kits, motors and other oddsNends.

 

[mikec]

Yes don't implement packet checking and sync until you have exhausted the XBee functions for that. You shouldn't need to write your own when Digi's will be better . The XBee pro only has 2 rf data rates. Slow and best link budget when your uart data rates is 9600 baud or less. Going slower than 9600 doesn't increase your link budget.

He's using an Xbee 3 Pro according to the original post, I presume in transparent mode (API mode is harder to use), but I don't know which of the three variants (Digimesh, Zigbee, or 802.15.4). I'm not sure, even if you have retransmit enabled, you can ever guarantee reliable stream delivery in transparent mode, and your serial data is going to be diced up into RF packets, so you always have to be prepared to deal with partial reception. I would look for the newline and then count commas to make sure you have a full message, or something similar.

 

[jderimig]

He's using an Xbee 3 Pro according to the original post, I presume in transparent mode (API mode is harder to use), but I don't know which of the three variants (Digimesh, Zigbee, or 802.15.4). I'm not sure, even if you have retransmit enabled, you can ever guarantee reliable stream delivery in transparent mode, and your serial data is going to be diced up into RF packets, so you always have to be prepared to deal with partial reception. I would look for the newline and then count commas to make sure you have a full message, or something similar.

I am not totally sure but I think you can enable CRC at the module level in a configuration register. If the CRC is not passed nothing gets sent from the UART. You may not get nothing sent but if you do, you can be reasonably sure the data is valid within the error probability of the CRC. Am I correct?

 

[StreuB1]

I am not totally sure but I think you can enable CRC at the module level in a configuration register. If the CRC is not passed nothing gets sent from the UART. You may not get nothing sent but if you do, you can be reasonably sure the data is valid within the error probability of the CRC. Am I correct?

If you implement hardware CRC and the result is a set register, you can query the register to validate if the packet stream was successful, if not, you can flag it. Easy way to troubleshoot in the beginning in case it doesn't work and you have no idea why.

 

[mikec]

I am not totally sure but I think you can enable CRC at the module level in a configuration register. If the CRC is not passed nothing gets sent from the UART. You may not get nothing sent but if you do, you can be reasonably sure the data is valid within the error probability of the CRC. Am I correct?

For the Digimesh version of the 3 Pro, all you can do is set the RR parameter (unicast MAC retries) and packets get retransmitted as needed below your level of visibility, at least in transparent mode. You can set RR to 0 if you want. https://www.digi.com/resources/documentation/Digidocs/90002277/

My experience is all with the 900 MHz Pro XSC, a dumber device, but I've never enabled RR and simply wrote my code to discard invalid messages between newlines.

 

[jderimig]

For the Digimesh version of the 3 Pro, all you can do is set the RR parameter (unicast MAC retries) and packets get retransmitted as needed below your level of visibility, at least in transparent mode. You can set RR to 0 if you want. https://www.digi.com/resources/documentation/Digidocs/90002277/

My experience is all with the 900 MHz Pro XSC, a dumber device, but I've never enabled RR and simply wrote my code to discard invalid messages between newlines.

I wouldn't use Digimesh. Don't need the extra overhead for a simple P2P telemetry app.
Here is excerpt from Digi XSC. Don't need to discard packets in SW, the module does that for you.

If the XBee pro 3 doesn't have this feature then I would suggest investing in an XSC. Life is too short to be doing packet validity checking in user code.

 

[mikec]

I wouldn't use Digimesh. Don't need the extra overhead for a simple P2P telemetry app.
Here is excerpt from Digi XSC. Don't need to discard packets in SW, the module does that for you.

If the XBee pro 3 doesn't have this feature then I would suggest investing in an XSC. Life is too short to be doing packet validity checking in user code.

I'm sure the OP and everyone else has long since lost interest, but the Pro 3 Digimesh in point-to-multipoint mode is doing the exact same thing the XSC is doing, and if you are running in transparent mode and sending messages longer than an RF packet (64 bytes on an XSC, on the Pro 3 they can be up to 73 bytes with encryption turned off) then you can lose a 64-byte chunk from the middle of the stream and you had best be prepared to live with that somehow. The only other solution is to make sure every message you send is shorter than 64 bytes.

Digimesh is complicated, but I don't think any more complicated than your other options with these modules. There's no real overhead in point-to-multipoint mode AFAIK.

 

[jderimig]

I'm sure the OP and everyone else has long since lost interest, but the Pro 3 Digimesh in point-to-multipoint mode is doing the exact same thing the XSC is doing, and if you are running in transparent mode and sending messages longer than an RF packet (64 bytes on an XSC, on the Pro 3 they can be up to 73 bytes with encryption turned off) then you can lose a 64-byte chunk from the middle of the stream and you had best be prepared to live with that somehow. The only other solution is to make sure every message you send is shorter than 64 bytes.

Digimesh is complicated, but I don't think any more complicated than your other options with these modules. There's no real overhead in point-to-multipoint mode AFAIK.

I am not even losing packets in a thing as long as you do the link budget calcs and run with a nice healthy margin of at least 10db. In our current system we have very little, negligable, packet loss with XSC and we have tested it to 70 miles in the air. No user code packet mitigation needed.

If the OP is losing packets on the bench then there is something seriously wrong.

 

[waltr]

Question to the OP and others on the Xbees.
Which Antenna option is everyone using?

There is a pretty big difference in range and link margin between the SM antenna and a rubber duck.

 

[waltr]

Guys i think i am dropping some data when sending with Xbee. I think this is the problem here other than line. Becuse when i send a small string with println. I am losing some of the characters also. My baud rate for both xbees are 115200. I am in AT mode for both coordinator and router.

Did you get this to work reliably?

One thought I have is how fast is the loop running that sends each string?
Is it possibly you are over running the UART's input?

 

[mikec]

Question to the OP and others on the Xbees.
Which Antenna option is everyone using?

I've only used 2.4 GHz Xbees for ground applications, they have a claimed max omni-to-omni range of only 2 miles. I've always used rubber ducks.

For 900 MHz XSC, I use a wire antenna on the flight side and a rubber duck on the ground station.

I don't think anyone concerned with range at all would ever use a chip antenna, I've never tried one.

 

[cerving]

I've only used 2.4 GHz Xbees for ground applications, they have a claimed max omni-to-omni range of only 2 miles. I've always used rubber ducks.

For 900 MHz XSC, I use a wire antenna on the flight side and a rubber duck on the ground station.

I don't think anyone concerned with range at all would ever use a chip antenna, I've never tried one.

Chip antennas essentially have no gain, but they're fine for WiFi/Bluetooth and similar short-range applications. They're an excellent alternative to a PCB antenna because they take up a lot less PCB space.

 

[waltr]

Chip antennas essentially have no gain, but they're fine for WiFi/Bluetooth and similar short-range applications. They're an excellent alternative to a PCB antenna because they take up a lot less PCB space.

Yep, that is why I asked what the OP and others are using.

I have used the older 900MHz XBees years ago. Chip antenna worked great to link to a small Bot running around in the same room.
Wire antenna ok to get to other rooms within the house but needed the duck to reach beyond my yard.

Never tried using Xbee in rockets or at any greater range.
My current favorite goto for rocket telemetry is your 900MHz telemetry modules for Eggfinders. Have also done mods to have full duplex on them.

 

[deepfreeze]

He's using an Xbee 3 Pro according to the original post, I presume in transparent mode (API mode is harder to use), but I don't know which of the three variants (Digimesh, Zigbee, or 802.15.4). I'm not sure, even if you have retransmit enabled, you can ever guarantee reliable stream delivery in transparent mode, and your serial data is going to be diced up into RF packets, so you always have to be prepared to deal with partial reception. I would look for the newline and then count commas to make sure you have a full message, or something similar.

I am using the Zigbee version.

 

[deepfreeze]

Question to the OP and others on the Xbees.
Which Antenna option is everyone using?

There is a pretty big difference in range and link margin between the SM antenna and a rubber duck.

I am using SM Antenna

 

[deepfreeze]

Did you get this to work reliably?

One thought I have is how fast is the loop running that sends each string?
Is it possibly you are over running the UART's input?

My baud rate is 9600. I don't have a delay in the loop if this is you are asking.

 

[waltr]

My baud rate is 9600. I don't have a delay in the loop if this is you are asking.

Yes, that is what I am asking.
It does take the XBEE some time to take the serial data, put it into a 'packet' then send it out the RF TX.
XBEE is also two way but can only TX or RX at any time and it is probably doing ACKs of the RF packets.

Even at 9600Baud you could be over running the Xbee's input FIFO. Have you tried lower Baud rates?

We did discuss Antennas a range in posts above. The SM antenna has a pretty short range (low link budget) and will never work in a rocket.

 

[deepfreeze]

Yes, that is what I am asking.
It does take the XBEE some time to take the serial data, put it into a 'packet' then send it out the RF TX.
XBEE is also two way but can only TX or RX at any time and it is probably doing ACKs of the RF packets.

Even at 9600Baud you could be over running the Xbee's input FIFO. Have you tried lower Baud rates?

We did discuss Antennas a range in posts above. The SM antenna has a pretty short range (low link budget) and will never work in a rocket.

I thought RP-SMa antennas are gonna be larger in terms of range.

I haven't tried lower baud rates, i will try and let you know.

 

[jderimig]

I thought RP-SMa antennas are gonna be larger in terms of range.

I haven't tried lower baud rates, i will try and let you know.

SMA is a connector. Standard 900Mhz (that is what you are using?) antenna's give plenty of range.

 

[deepfreeze]

I thought RP-SMa antennas are gonna be larger in terms of range.

I haven't tried lower baud rates, i will try and let you know.

I tried with 1200 baud rate. Data is coming too slow. I lost less packages but still losing some.
Also btw I put 1 second delay in my code, the data is alright.

 

[deepfreeze]

SMA is a connector. Standard 900Mhz (that is what you are using?) antenna's give plenty of range.

Here is what i am using.

 

[jderimig]

Antenna is good. What is power and freq of the module?

If you do not already know this there is an excellent link budget calculator here:

Loading…

www.pasternack.com

Good background here:

http://www.sss-mag.com/pdf/an9804.pdf

I'd be curious what the link budget is given your module(s) and your needed distance.

 

[waltr]

Ahhh....when you said SM antenna I read that as Surface Mount.....which is one of the Xbee options.
SMA with a rubber duck antenna will give the best range.

I tried with 1200 baud rate. Data is coming too slow. I lost less packages but still losing some.
Also btw I put 1 second delay in my code, the data is alright.

with a delay between data groups the output from the Receiving Xbee is ok.
This indicates the Xbee needs some time to send all the data arriving and clear out its FIFO.

Now increase the Baud rate with the delay between data groups to find what works best.
Then decease the delay.

 

[cerving]

One hint on antennas... get good ones that you have the specs for (such as from Linx), any antenna you get on eBay/Amazon is most likely junk. A lot of the "900 MHz" antennas from those guys are crappy tri-band antennas that aren't as good as a properly trimmed piece of wire.

 

[jderimig]

I tried with 1200 baud rate. Data is coming too slow. I lost less packages but still losing some.
Also btw I put 1 second delay in my code, the data is alright.

The Xbee should have hardware flow control. Can you use that on the Arduino side? Or poll the CTS bits in an Xbee register?

 

[QFactor]

Never tried using Xbee in rockets or at any greater range.

Just a quick note - the trackers by Missile Works use XBees. Antennas can be RP-SMA or the single wire.

 

[mikec]

There are many kinds of XBees, and the one the OP is using (Xbee 3 Pro Zigbee) is quite different from the 900 MHz XBee Pro XSC that is most used in rockets. I have no idea what data rate constraints the Zigbee might have, and https://www.digi.com/resources/documentation/digidocs/90001539/ isn't very clear about this. Considering the RF rate is 250 kb/s, you'd think 9600 baud would be no problem even without flow control, but Zigbee may be pretty heavyweight for a simple transparent point-to-point UART application.

You could always just run another version of the firmware and ditch Zigbee, though the others might be equally confusing in some other way.