Replies to This Discussion

Permalink Reply by James Churchill on August 4, 2012 at 8:12am

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.

Permalink Reply by Justin on October 11, 2012 at 2:22pm

Hi Seppo,

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 :)

Permalink Reply by Jake Stew on August 4, 2012 at 2:25pm

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

• ▶ Reply

Permalink Reply by Justin on August 4, 2012 at 6:01pm

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!)

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on August 4, 2012 at 6:28pm

No, Xbees are not open source. That's why we developed the 3DR radios, which are. 

• ▶ Reply

Permalink Reply by Justin on August 4, 2012 at 10:58pm

I know the Xbee's are not open source, I was reffering to using them instead of the 3DR until encryption is available.

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on August 4, 2012 at 11:02pm

My apologies; I was reading too fast. 

• ▶ Reply

Permalink Reply by Seppo on August 4, 2012 at 6:32pm

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.

• ▶ Reply

Permalink Reply by Justin on August 4, 2012 at 11:04pm

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.

• ▶ Reply

Permalink Reply by Jake Stew on August 5, 2012 at 6:56pm

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.

• ▶ Reply

Permalink Reply by Justin on August 5, 2012 at 7:03pm

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.

• ▶ Reply

Permalink Reply by Jake Stew on August 5, 2012 at 7:56pm

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.  

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page