Bootloading, Terminal Interface, and WiFi

[NZ0I]

I discovered the problem with bootloading using the newer version of AVRdude. It was actually a hardware issue, but by chance I had only noticed the problem when using the newer AVRdude version: but the problem was there all along. The problem was that I had both the FTDI cable and the Control Head connected to the Digital Interface board's serial port. That is not allowed. Having the RXD lines of two devices connected together is OK, but connecting two or more TXD lines causes problems because both devices attempt to drive the same line. The problem is easily solved by AND-gating together any TXD lines going to a single RXD port. 

So bootloading is working properly now, and the latest AVRdude software does automatically reset the processor provided that the FTDI cable's RTS line is connected to the processor's RESET line by a 0.1uF capacitor.

A simple command interface is now in place to allow the receiver to be controlled via a dumb terminal (PC). Just connect the FTDI cable between the PC and receiver, start the terminal emulator program (PuTTY, and Arduino IDE's Serial Monitor both work just fine), and press the Enter key. The receiver will respond with the RDP> prompt. A short session is shown below. Pressing Return, or entering an illegal command, causes the receiver to print out a list of valid commands.

RDP>

*** ARDF Dual-Band Receiver Ver. 0.3 ***

Commands:

   BND [2|80]        - Rx Band

   FRE [Hz]          - Rx Freq

   FRE M<1:5> [Hz]   - Rx Mem

   S                 - RSSI

   TIM [hh:mm:ss]    - RTC Time

   VOL <M:T> [0-100] - Main/Tone Vol

   ?                 - Info

RDP> FRE

> FRE=145520000

RDP> BND

> BND=2m

RDP> TIM 20:45:20

> TIME=20:45:20

RDP>

Commands with no data cause the receiver to return the current setting. Commands with data cause settings to be changed. Currently you can control the frequency, band, memories, volume, real-time clock, and read the signal strength and battery levels.  We can add more commands as needed. Backspace is supported for correcting typing errors.

This functionality should now allow us to control the receiver (and transmitter too) via WiFi using a wireless TCP-to-UART converter. If you've heard of Piglet, that is an example of a wireless TCP-to-UART converter. Piglet costs $100 and is a bit of a power hog. But it appears that we could add the same WiFi capabilities using this device: https://www.digikey.com/products/en?keywords=RN1810-I%2FRM100-ND, which is much less expensive and less piggish with power.

The real beauty of having WiFi support, I think, won't be using your PC to wirelessly control your receiver or transmitter, but using your smartphone! There are apps available right now for both Android and iPhone that turn your phone into a "dumb TCP terminal" capable of sending serial text over WiFi to a TCP endpoint. So there will be no need to lug a laptop out to the forest; if you need to configure a transmitter or receiver you'll be able to use your smartphone or tablet. A specialized app could be written to make configuring and synchronizing transmitters and receivers very simple and portable. Cloning should also be possible over WiFi, eliminating the need for cables and connectors. Perhaps a "Control Head" app could be written to replace the user interface for the receiver - that approach might eliminate the need for a Control Head altogether.

I've got a Piglet in my possession, and I may try hooking it up just to demonstrate the concept.

[NZ0I]

I opened up my Piglet and discovered that it contains an RN171 device.

Looking at their specs, the main difference between RN171 and the RN1810 seems to be the firmware support that they contain, and of course the price. The RN171 can function as a standalone embedded wireless LAN access device. The RN1810 by contrast incorporates an on-board TCP/IP networking stack, and can independently maintain a low-power wireless network connection. Hardware-wise they seem to be nearly identical. And since they are complete modules, they are FCC and CE certified independently - so we don't need to be concerned about compliance issues.

Unfortunately, I think we may want to go with the RN171 ($27), or a functionally-equivalent device. I'll look around for existing open source software for interfacing with both devices. 

The upside of the RN171 is that we can compare it with the Piglet features, and be confident that we can achieve the same functionality since the Piglet is using the exact same device.

[NZ0I]

Another note: both the RN171 and the RN1810 contain their own Real-time clocks. So if a WiFi module is included, the $8 real-time clock device can be dropped, partially offsetting the added cost of the WiFi module.

On Saturday, May 27, 2017 at 9:30:08 PM UTC-4, NZ0I wrote:

[Gerald Boyd]

The whole wifi idea is real cool. I like the idea of getting rid of interface cables. One less item to keep track of. 

Also can help waterproof the box with less connections to seal. If we made the smart phone the user interface would need to address that for ARDF rules. 

If being used as a transmitter controller that had a built in gps could it be programmed to look for an open wifi to call home if it detected that it was removed with out permission? The reason I bring this idea up is we had somebody steal a bunch of orenterring controls on our last orienteering meet I ran. That's an interesting story as I had to call law enforcement to come out to the meet location.

The transmitter could monitor its gps position ( or maybe a multi axis accel) to see if it's being moved without permission . Before moving the transmitter the user could send a location unlock.

Could even be done to lock a receiver in impound.

Just an idea.

Sent from my iPad

--
You received this message because you are subscribed to the Google Groups "Receiver Development Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/61155cc2-376a-424e-a4ee-4a077d1bda3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Charles Scharlau]

Hi Gerald,

Theoretically it might be possible to program the WiFi to scan for insecure network hubs with which to connect and report its position. But I think that insecure access points are becoming pretty rare. Cellular network connectivity on the other hand is becoming harder and harder to avoid. So this product, or something like it, might work better to implement a theft reporting feature: https://www.adafruit.com/product/3234. That might also be a reasonable solution for remotely turning on the transmitters, but a little pricey... and some ARDF venues may never have cellular coverage.

GPS or an accelerometer could be used to give the transmitter the ability to sense that it is in motion. 

I rather like this idea for exacting instant justice if a thief dares touch a control or transmitter: https://www.premier1supplies.com/p/pig-quikfence-6-30-12-electric-netting. You don't need the fence if you attach the energizer to the metal transmitter housing ;-)

To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development-platform+unsub...@googlegroups.com.

[NZ0I]

Regarding having the rules address the issue of using a smartphone for the receiver user interface: it should be allowed, and easily handled. I've posted some of my thoughts here: http://openardf.org/index.php/2017/05/29/ardf-and-gps-continued/

The receiver's user interface app could be made open source, so that everyone could see that is doesn't include functionality that would allow one to cheat. It could also access the GPS in the smartphone and record one's track to a file, and perform just like what I've suggested in the blog post linked to above - proving that the cellphone capabilities, and other apps, were never used during the course of a competition.

On Saturday, May 27, 2017 at 9:30:08 PM UTC-4, NZ0I wrote:

[Gerald Boyd]

Very good posting. I agree that technology can address the issues with unfair advantage ( cheating).

We did have someone with a medical issue on the last championship we hosted. The emergency panic button feature with position beacon and type of emergency would have come in real handy. 

We realized something was wrong the old school way when enough time had elapsed and course marshals reports did not see the persons bib number show up at other controls. 

We sent out rescue teams from the last point seen and found the person. The panic button would have saved a lot of time. Had a happy ending for this case. However a different type of emergency with a time critical need could have had a different outcome.

Should we bring this topic up at the national champs this summer and see what the response is?  I am in the support camp for features like this.

Sent from my iPad

--

You received this message because you are subscribed to the Google Groups "Receiver Development Platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/d1911a54-625d-4f56-8c8d-4d5cf3645bf0%40googlegroups.com.