Close

3DR Radio for remote control

A project log for Ultimate running aid

Eliminate everything from running but the running part.

lion-mclionheadlion mclionhead 11/23/2018 at 09:480 Comments

The 3DR Radio/HM-TRP/Si1000 modules don't have any GPIOs like the XBee.  It was desperately hoped that the XBee could eliminate the need for a companion microcontroller with GPIOs.  Making custom Xbee firmware requires the EmberZNet SDK which is only available to owners of the $1000 EM35X-DEV kit.   With so much interference at 2.4Ghz, a broken channel changing command & no way to write custom firmware, they're worthless junk now.

The lion kingdom replaced the firmware on its 3DR Radio to optimize it for transporting PPP instead of telemetry.  It didn't work because of lockups in the USB to serial adapters but might have worked with custom USB adapters.   That firmware is now lost forever & must be reverted.

The stock 3DRRadio ran the SiK firmware.  In a testament to the commoditization of quad copters, the SiK firmware no longer compiles on any modern Linux version.  It was only ever used for moving quad copter telemetry to a laptop.

The SiK issues were minor compiler errors from evaluating all constants to int instead of uint8_t & the default switch statement overriding all other cases with a the same rule.

How to build & program it is still documented in the README.markdown file.  Besides ending every file in .markdown, this author also liked using ~ all over the filenames.  The lion kingdom's boards still had the grounding connections required to program the firmware.

The firmware update command is:

Firmware/tools/uploader.py --port /dev/ttyUSB1 Firmware/dst/radio~hm_trp.ihx

Many users got "Verification failed in group at 0x0" errors.

The mane cause of "Verification failed in group at 0x0" is trying to program a file starting in bootloader~.  The bootloader can't program itself.  You have to program a file starting in radio~.  The mane reason for this confusion is the ~ is normally the start of a directory name in Linux so we ignore everything before it.  

With the firmware programmed, you have to configure them.  This is done in the AT command mode just like the Xbee.  ATI5 gives the default settings.  The baud rate is limited by the air data rate.  The only essential thing is reducing the latency.  They don't pass keyboard input through without reducing this.

ATS15=33

AT&W

ATZ

The goog still manages to find documentation on the ground connection required to enter bootloader mode & the AT commands.

With the 3DRRadios installed, power consumption dropped from over 100mA to 40mA.  The update rate remaned stuck at 50hz & jittery.  Ideally, the update rate would be 100Hz & even.  There's no way to do that without custom firmware, but it's not worth it.

New old radio installed with some effort at keeping the antenna from breaking off.

3DRRadios broken apart.

Stick controller with new old radio.

The 1st 8 miles with this were a total disaster.  The 3DRRadio dropped connections randomly & would never reconnect until the vehicle module was power cycled.  Some of the problems were brief power glitches on the stick.  If the stick radio was power cycled, it would never reconnect until the vehicle radio was power cycled.  

At other times, it dropped the connection when stopping the throttle.  The radio appeared to die before the stop command reached the vehicle.  Fortunately, the vehicle had a 1 second timeout & breaking enabled.  The throttle glitches pointed to something more sinister than power glitches, but either way, the stock 3DRRadio was trash.

The next step would be the non frequency hopping XBee 900's from 10 years ago.  They would be another bandaid while working on the 3DR's.  They would also reveal any interference where the 3DR's failed.

Discussions