I know the Pro 900 XSC has about 4x the range of the Pro 900, but that it's data rate is only 9.6kbps.
Is this enough for full duplex telemetry and on the fly route updates from the mission planner or am I better off going for the Pro 900?
I'd love the Xtend 900 but it's a little pricey compared :( but who wouldn't love a 60km+ range?!?
I'm just not too keen on the 3DR radio so I've decided to stick with the Xbees which I've used before.
Also how much difference in range would you expect to get using the wire whip vs the RPSMA connector with an omni antenna?
Since we've got somewhere between 4 and 10 free bytes of ram at present ("8051: Everything is Global!" *sigh*) implementing new functionality alongside SiK is not really feasible.
Just wondering if there's been any thoughts on moving to the Si1034 platform or if it's in progress?
I'm still eager for an RFD900 equivalent with encryption for a similar price :)
Encryption is certainly needed and should be one of the core features of the data stream protocol.
91 bytes of ram and 3156 bytes of flash for a complete encryption solution is a trivial amount.
The Si1000 chip has 64kb of flash and 4.25k of ram.
91 / 4352 = 2% of ram.
3156 / 65536 = 5% of flash.
Encryption is more like a 25% value feature, so it is a bargain for 5%. Because the 3DR/SiK firmware is tied to the MP, we need to rely on cooperation from the devs to remove code bloat and prioritize features. It would have been really nice if they had budgeted some free space for others to use and for new features. Hogging up all the space right away makes it hard to move forward.
43 bytes of ram and 1056 bytes of code space for the encryption module, and 48/2100
These radio's are open source aren't they? Surely amongst everyone there should be some optimisations that can be made to free up a little more RAM & flash?
If there's no hope I'll just use some Xbee 900's and hope that in the not too distant future there's a new board that supports it! (I'm happy to be a beta tester when the time comes!)
No, Xbees are not open source. That's why we developed the 3DR radios, which are.
I know the Xbee's are not open source, I was reffering to using them instead of the 3DR until encryption is available.
My apologies; I was reading too fast.
There is certainly scope to improve memory usage - the serial rx buffer is around 2k of ram at present!.
At the moment, the code is structured such that the buffer size is 2^n. The buffer size on XBee's IIRC is in the order of a few hundred (150?) or so bytes. APM1,2 at the moment do not support hardware flow control but some new generations may. The RFD900/3DR radios do support HW flow control, so working with smaller buffers is definitely an option.
Unfortunately I don't think I'd be very well suited to freeing up resources as I've never worked with code for radios or communications protocols. That's why I've always used Xbee's as they do the hard work for you.
Perhaps a silly question, but could you not just make the rx buffer 1.5k instead for the extra room? Then you'd just need to free up a little bit of flash.
That's good to know. I haven't had time to poke around in the code yet.
I would think software flow control would work fine. I also wonder about how necessary the error detection/correction is. Mavlink already has error detection and it seems a bit excessive to implement it at the physical layer and in the protocol.
Most of the data is time sensitive, so there's no point in retransmitting anyways.
Although some of it may be time critical, other things would be critical regardless of it it arrived late. If a stop command was required and it wasn't re-transmitted, a delay would clearly be preferable to missing it all together. I don't think you could substitute error correction for anything else in that case.
What I'm trying to say is that there's no point in error correction on multiple layers.
We could have error detection/correction on the physical, transport, and application layers, but each extra one just wastes bandwidth and resources.
The vast majority of the telemetry is time sensitive. Gyro, barometer, etc. are all one time deals, it doesn't make any sense to try and retransmit them. Commands should all have acknowledgments, which should be an application level deal.