900MHz Wireless Embedded Systems Programming

[pomprocker]

Check this link out:

http://www.rentron.com/PicBasic/wireless.htm


Now, how to do this cheaper and with an ATmega?

Looks like those modems cost $300+


-Brandt

[pomprocker]

I got an email correspondance with  the guy who did the research on this:

Hi Bruce,

I've been trying to implement something like this for a long time with no success.

I'm using an ATmega168@8MHz, a BlueSMiRF Gold on the MCU-UART running at 8-1-n 5700 baud, and using the watchdog timer to reset the MCU. The bootloader I am using is "Fast, Tiny, & Mega" found on the avrfreaks.com website.

Apparantely this combination is not working for wireless programming. I am using it on a mobile robot platform, therefore I can't use anything that plugs into a wall recepticle. Also the modem you discuss looks to be out of my price range.

I don't know if you would be able to help me with my setup, or maybe you could just share with me the secret inner-workings of the communication protocol needed for this wireless programming to work.

Thanks,
Brandt

On Mon, Dec 1, 2008 at 3:55 PM, Tech <email omitted> wrote:

    Hi Brandt,

    Wireless boot-loading requires a pretty in depth knowledge of the RF hardware, boot-loader
    firmware, and the embedded controller. Unfortunately, I know zero about the BlueSMiRF Gold
    or your loader firmware - so I can't offer a lot of help with these.

    I did look up the BlueSMiRF Gold, and it mentions 'encrypted' data, so this may be a big stumbling
    block if you're waiting for encryption/decryption, but I'm not sure what the timing is on this.

    What you want for something like this is a straight-forward wireless link, without any encryption/decryption
    stuff going on in between. And a true full-duplex 'bi-directional link" + some way to reset the remote controller
    when the PC software initiates the loader process.

    Bi-directional 'full-duplex' is the real key here. Most RF units listed as bi-directional aren't full-duplex.

    They operate in half-duplex mode, which means the receiving unit has to receive data first, then it sends
    data back. This causes big problems when the firmware/hardware is expecting to be able to transmit & receive
    at the same time - like most all boot-loaders.

    I really couldn't tell you what may or may not be required without having your hardware/software setup to test.

    If you want the pair of SuperSCREAMER radios used for this project, I'll let you have them at less than 1/2 the
    original cost.

    I couldn't even tell you for sure if they would work with your particular loader firmware, but I do know they
    work for this application. I was going to offer them on the project page, but if you want them, I'll hold em for you.

    Note: This is just for the SuperSCREAMER radios. The custom DB9 adapters were sent to the company that
    originally hired us to build this.



    Regards,

    Bruce
 

[Admin]

This causes big problems when the firmware/hardware is expecting to be able to transmit & receive
    at the same time - like most all boot-loaders.

Hmmmm according to him we need a full duplex bluetooth wireless modem if we want wireless bootloading . . . have you tried any full duplex wireless xmitters?

An idea . . . get two transmit/receive wireless modem pairs, one at 900MHz and one at 450MHz. Have them both run at the same time to create full duplex. It must be at different frequencies so that the signals don't collide.

A quick way to verify if the bootloader requires full duplex is to disable the Tx line on your microcontroller during the boot phase and see if it still works. (I don't think it will)

[Asellith]

Just a random thought why can't you put a second smaller MCU in the chain and have it act like a buffer? The other mcu would just receive the files from the wireless link and store them then initiate the bootloader sequence. I don't know much about bootloaders so this might not be possible but make sense in my head. You'd basically send the code to the other mcu in a hex file then make that mcu a bootloader all by itself.

[pomprocker]

Aselith, I though of something just like that, but to use an external eeprom chip instead...

[pomprocker]

This causes big problems when the firmware/hardware is expecting to be able to transmit & receive
    at the same time - like most all boot-loaders.

Hmmmm according to him we need a full duplex bluetooth wireless modem if we want wireless bootloading . . . have you tried any full duplex wireless xmitters?

An idea . . . get two transmit/receive wireless modem pairs, one at 900MHz and one at 450MHz. Have them both run at the same time to create full duplex. It must be at different frequencies so that the signals don't collide.

A quick way to verify if the bootloader requires full duplex is to disable the Tx line on your microcontroller during the boot phase and see if it still works. (I don't think it will)

The bluesmirf is also listed as having an encrypted connection, which may slow things up.