Hi Everyone,

I thought it might be useful to give a bit of background on what this forum is for.

3DRobotics have just released a set of telemetry radios based on the Si1000 chipset. The ArduPilot developers (particularly Mike Smith and myself) have been working hard on the firmware for these radios for months now, trying to make them ideal for APM telemetry.

These radios are unusual as they are open source and extremely configurable. That means that there is a lot of scope for diydrones members to get involved in tuning of the radios, and in adding new functionality. That is what this forum is for.

The Si1000 chipset has a huge number of configuration registers. We've spent quite a lot of time selecting the best register values for use with APM, but there is still a lot of scope for more experimentation. For example, I'm planning to do a test flight soon to see if enabling manchester encoding gives better or worse range at various data rates.

Similarly, there is a lot of scope for adding firmware features to make these radios link really well with antenna trackers and other radio add ons. We've already got them talking to APM in a much more advanced way than an Xbee can, but there is a lot of scope for taking it even further.

The basic theme is that these are DIY radios. We've put together functionality to make them work really well already, but the real potential is from the community getting involved to make them even better.

So get involved, and let's bring to telemetry radios the same sort of community development that has made ArduPilot so much fun to be involved with!

Cheers, Tridge

Tags: 3DR, radio, telemetry

Views: 3318

Reply to This

Replies to This Discussion

This would be great for ham radio APRS to track balloons and other aircraft via aprs. I ordered 3 units to experiment with in the 433mhz band. Imagine an APM2.0 on a balloon with this radio sending Mavlink data via the APRS system. I am involved with a group doing a balloon launch this fall so I will bring this radio to their attention. By putting the APRS on the internet, a lot of people can watch this launch in real time. Now to figure how to take pictures and put them on internet at the same time. That would be cool.

Earl

Hi Earl,

If you are willing to put in a bit more work, the other possibility is to use this radio as the controller for the balloon. You could attach a small GPS to the serial port and the radio would transmit the GPS data to the ground station.

Of course, adding an APM2 gives you a lot more sensors, so if the extra bit of weight isn't a problem then that would work too, but for really lightweight balloon flights the radio itself should be enough.

Cheers, Tridge

Tridge, many thanks for the work in doing this.  I've had such bad luck with xbees that I never want to depend on them.

I tried ordering a set, but it's backordered due to an apparent shortage of header pins.  Hope those are easy to get somewhere! :-)

I'm glad you've gotten a radio together and in production!  When I came up with the idea and posted it last September there didn't seem to be a whole lot of discussion.  Looks like you guys did a good job on the software.

I'd have done the hardware a bit different, instead of just making carrier boards for HopeRF modules, but it's still a great leap forward from crappy xbees.

Hi Jake,

I'd be interested in hearing how you would have done the boards differently. I'm sure this won't be the last radio I help develop, and I'm always interested in getting ideas from other diydrones members. (the 3DR radios are the first radio firmware I've been involved with).

One thing I would have liked to see myself is a radio module with forward error correction in hardware (eg. Viterbi encoding/decoding). That would really help for long range, but unfortunately I don't know of a low cost module that has FEC plus decent power levels. I added a Golay code for the 3DR radios to offset the lack of FEC somewhat, but hardware error correction would certainly be a nice feature.

Cheers, Tridge

The main thing I would have done differently was expose some pins on the Si 1000.  The digital crossbar in the Si chip makes even a few pins very useful as you can map almost any function to any pin.

The obvious thing to do with these pins would be to run PWM outputs.  If you had 4-8 PWM outputs you would then have a complete receiver replacement.  The cost and weight savings would make the radio that much more useful.

Another thing is that I wouldn't have used a module.  If you're doing a board you might as well do the whole thing.  I've never been very impressed with HopeRF modules.  IMHO their RF design is not that great.  I would prefer the SiLabs reference design over theirs.  They only spec their modules at a receive sensitivity of -117dBm.  The reference spec is -121dBm, and I can't see the advantage of losing 4dBm of link budget just to save having to place a dozen or so components.

I also question the module connection.  Having that raised 90 degree solder joint in your TX/RX path isn't optimal.  The impedance around that joint can't be maintained as the path deviates from the ground too far. To me that would be like removing the shielding from several mm of coax cable and replacing it with a loose wire to connect the shield back up.  That screws up the impedance and allows RF leakage.

On the ground end I would have just used a TTL to USB cable instead of using a board mounted chip.  The cables are cheap and you could then have identical air and ground modules.  On the ground end you could use the exposed uC pins to drive a PWM antenna tracker or any of another million ideas.

One of the main things I would have done is leave more room for development, e.g. expose more pins.  The Atmega 2560 of the APM2 only has 16 MIPS of processing power.  The SiLabs chip used in the radio has 25 MIPS, so that begs the question why not use it?

Since the SiLabs radio chip has almost twice the processing power of the APM 2.0 uC why not do more with it?  I would not put it past a skilled programmer to make a 1 chip complete autopilot solution (less the sensors of course).  You can argue about ARM MIPS vs 8051 MIPS, but it's certainly within the realm of possibility that you could have a radio + autopilot all in one chip.

The APM 3.0 may already be here and we don't even know it.  I wouldn't be quite that ambitious with the radio, but it wouldn't be that difficult to implement 6+ PWMs and use the radio as a complete RC TX/RX replacement and datalink.  With a little bit of work on packet prioritization and bandwidth allocation it would be a pretty nice system.  Everything would be controlled through the computer/joystick.  Alternately you could do a PPM decoder scheme on the ground side and use off the shelf RC controllers as control input. 

I've done up a few schematics based on the SiLabs reference design with exposed pins arranged for PWM outputs.  However, the tech keeps outpacing me and I already have my heart set on that type of design with a 1W amplifier.  Kicking up the power to something in the 40km+ range will open up a lot of UAV applications.

I'm glad the radio is out!  The added power, additional sensitivity, and lower cost are going to make the crappy xbees a thing of the past.  Just get the ordering going so I can get a unit!  I can't make a better radio for $75, unless I value my time below minimum wage, so I want one NOW!

-Jake

Hi Jake,

While its a nice idea to do an autopilot on the Si1000, it just wouldn't fit. The Si1000 has 64k of flash, and we are using 52k of that for the radio functionality we have now. So we would have 12k of 8051 code space to fit the 137k of APM2 2560 functionality in.

It also doesn't have nearly enough memory. We're down to just a few bytes of memory left with the current radio functionality. Each time I add a variable I need to look around to find a couple of bytes I can save somewhere else.

Here is the memory map from the current 3DR radio firmware:

Internal RAM layout:
      0 1 2 3 4 5 6 7 8 9 A B C D E F
0x00:|0|0|0|0|0|0|0|0|a|a|a|a|a|a|a|a|
0x10:|a|a|a|a|b|b|c|c|e|e|e|h|h|h| | |
0x20:|B|B|B|B|B|B|B|T|d|d|d|d|d|d|d|d|
0x30:|d|d|d|d|d|d|f|f|f|f|f|f|f|f|f|f|
0x40:|f|g|g|g|g|g|g|g|g|i|i|i|i|j|j|j|
0x50:|j|j|j|j|j|j|j|j|j|j|j|j|j|j|j|j|
0x60:|j|j|j|j|k|k|k|l|l|l|l|Q|Q|Q|Q|Q|
0x70:|Q|Q|Q|Q|I|I|I|I|I|I|I|I|I|I|I|I|
0x80:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0x90:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xa0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xb0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xc0:| | | | | | | | | | | | | | | | |
0xd0:| | | | | | | | | | | | | | | | |
0xe0:| | | | | | | | | | | | | | | | |
0xf0:| | | | | | | | | | | | | | | | |
0-3:Reg Banks, T:Bit regs, a-z:Data, B:Bits, Q:Overlay, I:iData, S:Stack, A:Absolute

Stack starts at: 0x80 (sp set to 0x7f) with 128 bytes available.

Other memory:
   Name             Start    End      Size     Max     
   ---------------- -------- -------- -------- --------
   PAGED EXT. RAM   0x0000   0x00f0     241      256   
   EXTERNAL RAM     0x00f1   0x0ffb    3851     4096   
   ROM/EPROM/FLASH  0x0000   0xd09e   52385    62464   

   Compromises might have to be made.  Cramming an entire autopilot into 64k would not be easy.  It's not something I'd attempt as I'd figure you need at least 128k for a decent autopilot.  However, there is a 128k version of the same chip (different package unfortunately), the Si1020.

   But, I think adding PWM for servo control could be done in less than 12k.  That would make it a complete solution for both telemetry and radio control.  It could serve as a failsafe for autopilot failures.

   Just throwing out ideas.  There's a lot of potential here.

But, I think adding PWM for servo control could be done in less than 12k.  That would make it a complete solution for both telemetry and radio control.  It could serve as a failsafe for autopilot failures.

yes, that might work. As you say, it would need a lot of pins exposed, which would raise the cost of the radio, but someone else could probably develop a version of the radio that does this.

Cheers, Tridge

One thing I forgot to mention... I would have increased the frequency a bit.

Everyone and their brother is cranking out 433 and 915 mhz units.  All of them that I've seen use these frequencies and/or just copy the reference design or use a module that copied the reference design.

If you tweak your component values for the PA matching network to filter just a hair higher you can get off those overused frequencies.

What I'm saying is that you'll get a lot less noise if you go either way from the standard, default ISM designs that are used for everything from electric meters to traffic lights.  I'd go higher since you're using a low-pass filter in the PA network.  Then you can always switch your frequency lower through software if you really need to.

-Jake

On other note on that... I'm curious what low-pass filter values HopeRF is using on these modules.

Some RF engineers like to catch that last largest ripple in the passband of their filter, so the filter ends up being just over the target frequency.

Otherwise they might have designed the filter at the top end of the frequency range.

Does anyone know what HopeRF used in the module?

Looking at the pics it also looks like the module is socketed?  Looks like there's header spacers or something between the module and the carrier board.

.

I'd be worried about running that TX/RX path willy-nilly unshielded with lots of right angles.  Is the module the DIP or SMD version?  Looks like the DIP version is just the SMD with some pins thrown on.

.

It also seems like the actual data rate is going to be limited by the 115.2kbps UART rate listed in the HopeRF module datasheet.  Is that all the faster it can go?  The radio should be able to do 256 kbps and the UART can clock to 230.4 kbps.  Have you played with this at all?

.

I ask because 230kbps is getting up to where digital video or pictures would start becoming usable.  Even 1 fps @ vga resolution would be very useful for IFR flying.  Hell, even 320x240 @ 1 fps would be better than nothing!

-Jake

RSS

Social Networking

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here

Groups

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service