Wireless programming ?

manuka

Senior Member
A local educational contact, long frustrated with managing the "snakes pit" of classroom USB-serial cable$ (& -ah-increasingly familiar with "other" UK schools micros), recently asked me why PICAXE wireless programming hasn't yet been developed.

Fair question! Today's e-devices increasingly consider wireless (especially BT/BLE) the norm but AFAIK this OTA (Over The Air) PICAXE holy grail died when UK firm Ciseco's URF/ERF modules ceased production ~2013. (Nottingham based Ciseco became "Wireless Things" & this was later bought by MXC/365 Agile)

Forum ponderings arose (c/w Rev.Ed's outline of "break" issues)-refer sample posts below & =>https://picaxeforum.co.uk/threads/poor-mans-erf-urf.24390/.

Goeytex's admirable OTA explorations with INHAOS LC-1000 2.4GHz modules (now LC-3000 updates?) looked promising but nothing definitive seems to have since emerged... Anyone ?
 

Attachments

Last edited:

Goeytex

Senior Member
Hi Stan,

The LC-1000/2000PA modules worked fine as I recall. These operate as a transparent UART. I did not pursue past a working prototype due to a seeming lack of interest. But it was fun figuring out how to do it ...

I see no Inhaos modules listed on Ebay at this time. If anyone is interested I suggest contacting "Momo" at www.inhaos.com to check on availability.

Goey
 

steliosm

Senior Member
Programming through Bluetooth would be great too, since most laptops/computer now come with Bluetooth. Unfortunately, Bluetooth Classic has it's own nightmares and the BLE version does not support the Serial Port Profile (SPP).
 

manuka

Senior Member
Ciseco's URF/ERF 2012 approach used TI's popular CC1110/CC1111 sub GHz SOC => https://www.ti.com/product/CC1110-CC1111
It's use in Mattel's 2010 era IM-ME kids messenger lead to much hacking !

The PICAXE store (& others) stocks an interesting SiLabs "Bluegiga" BLED112 dongle. This is NOT a conventional BT adapter but a ‘BLE to serial’ that creates a virtual COM port -suiting Chrome & older Win systems that don't support BLE by default. I've no BLED112 experiences - any thoughts?

But surely the Ciseco/Rev.Ed brainpower & design that went into the URF/ERF were not just discarded... ?
 

Attachments

Last edited:

steliosm

Senior Member
The virtual com port over BLE is very appealing. I would also consider to use a HC-05 legacy Bluetooth module.
 

erco

Senior Member
Yes, wireless would be awesome. I had forgotten goeytex efforts. goey, if you perceived any lack of interest, mia culpa!

The little orange Australian Edison educational robot isn't wireless, but its novel 'EdCom' programming cable plugs into the HEADPHONE jack of the PC instead of USB. It appears to use optical LED couplings on the robot end. The lady in this video says max volume works best.

 

manuka

Senior Member
Interesting -I'd initially thought it used IR data (much as did/does Lego Technic). PICAXE IR handling is of course very comprehensive & may well have some "wireless mileage".
 

johndo

Member
I have a couple of HC-12 serial modules laying around. Would these in theory work all things being equal? These modules are apparently half duplex, do you need full duplex to work properly aside from the "break" command and other issues?
Please excuse my newbie questions...:)
 

manuka

Senior Member
HC-12 modules are/were great for longer range ~433 MHz data comms but are unlikely to suit. As well as indeed being half duplex they are physically LARGE (somewhat due to their low UHF antenna). A short range 2.4GHz approach -much in the style of Ciseco's URF/ERF - is what's needed.
 

Attachments

Last edited:

johndo

Member
Thanks for that info Manuka...

Would any of these modules work in theory???

AT-09?

HM-10?

JDY-40?

I played around with the HC-12 for a while and could never get them to work with OTA programming. Have written some code to a 08M2 to emulate the "break" command which seems to do what is intended but the issues are with the modules. So to save flogging a dead horse, a module that could theoretically work would be a good starting point, then experiment from there.

I'm still working on my water tank project and it would be great to be able to program the controller wirelessly from my office whilst having the controller sealed and in situ with all hardware finished and be able to fine tune the code without having to go outside all the time...

Any thoughts?
 

manuka

Senior Member
Yes indeed -OTA (over the air) programming /reprogramming/interfacing is state of the art -end users increasingly hate cables!
Your 08M break code sounds interesting -please post. Perhaps try Goeytex's LC-1000 approach?
 

hippy

Technical Support
Staff member
Have written some code to a 08M2 to emulate the "break" command which seems to do what is intended but the issues are with the modules. So to save flogging a dead horse, a module that could theoretically work would be a good starting point, then experiment from there.
The main problem with wireless programming is the Break Signal has to be maintained until the PICAXE has responded. That cannot be achieved using just a module which only transfers 8-bit data. The module either needs to support break signalling or an external controller has to be added and that's tricky to do.

It's also not just the receiving end; the transmitting end needs to get the Break Signal activation and deactivation to the receiving end in a timely manner. That is what Ciseco integrated into their products, simplified below -

URF / SRF
Code:
     .---------------------------------------.
     |     .--------------.                  |
     |  .->| Break Detect |--.               |
PC   |  |  `--------------'  |               |  \|/
     |  |               .----^----.  .----.  |   |
---->|--^-------------->| Encoder |->|    |  |   |
     |                  |---------|  | RF |--|---'
<----|------------------| Decoder |<-|    |  |
     |                  `---------'  `----'  |
     `---------------------------------------'
ERF
Code:
     .---------------------------------------.
     |                  .--------------.     |
     |               .->| Break Signal |--.  |
\|/  |               |  `--------------'  |  | PICAXE
 |   |  .----.  .----^----.               |  |
 |   |  |    |->| Decoder |-------------->O--|---->
 `---|--| RF |  |---------|                  |
     |  |    |<-| Encoder |<-----------------|<----
     |  `----'  `---------'                  |
     `---------------------------------------'
Then, for a universal solution, it's not just Break Signalling which has to be transferred from the PC side to the PICAXE side; it is Baud Rate setting as well. Ciseco could handle Break Signalling and Baud Rate Change because they used a USB interface, with the PC Device Driver having separate channels for those and data over USB. It is not so easy without USB.

The system also has to be able to cope with sending a Break while the PICAXE may be continuously transmitting, such as with DEBUG or in a tight loop, or it will be extremely difficult to download once it is doing that.

It is not that it cannot be done, it's the challenge of achieving it. Ciseco invested time and effort into integrating it all into simple modules and the same would need to be done for any DIY alternative. One either needs to modify the firmware within the modules used or one has to handle that externally.

If Goeytex's LC-1000 implements the same as Ciseco, or a subset, that may well work. I will admit I haven't really followed that effort so cannot say.
 

Goeytex

Senior Member
It was 8 years ago that I did that project and I don't remember a few of the details. I just looked at the code and it looks like Greek to me now.

It is indeed similar to how Ciseco did it. There is Host (master) module and a Client (slave) module, one consisting of an LC-1000 (Master) RF module and a Picaxe 14M2 and the other consisting of an LC-1000 Slave Module and a Picaxe 14M2 . These Inhaos modules pair up like BlueTooth and are serial enabled. There is no command set (like AT commands). Once configured and paired, simply send serial data to the master and it appears on the TX output of the slave. So basically a wireless serial port arrangement.

The biggest challenge was to figure out the "break signaling"as the LC-1000 does not support it . The Program Editor sends a "break" for up to 5 seconds. After 5 seconds it times out with an error if there is no response. Break signaling was handled by the 14M2's which are adequate, as no high speed processing is needed and the host application (Program editor 5) is very tolerant of timing deviations. You have ~100 ms to send an ACK back to the App after receiving a byte of data. There is a checksum in there somewhere( for configuring the RF Modlules) , so all in all not too complicated. But looking back, these modules DO support Wireless DTR Where the Master can set DTR on the Slave for any length of time. DTR might could be OR'ed with the serial line to act as a break signal on the slave unit possibly eliminating the need for the slave Picaxe.

But if I had to do it over again, I would likely consider a Master side micro-controller with more program memory ( not in slots). Where an option might be to store the Target Program in a large lookup table. Several "Popular" (per Microchip) 14 Pin PICS now have up to 64Kb of flash memory. This could make for a nifty remote programmer, not much larger than a KeyFOB if done with SMT components .

I would also consider exploring the use of LoRa modules as an alternative where long range might be needed. Who wants to climb up a tree or a 200ft tower to update their Picaxe code when it can be done from several kilometers away? I am guessing that this could(LoRa) done one-off for about $50 each or maybe a bit less.

You will need a cheap 8 Channel Logic Analyzer to sniff the data while programming a Picaxe to develop this stuff. Don't even try without one.


Goey

Edited to correct typos and poor grammar
 
Last edited:

johndo

Member
The "break" signal at the PC end is the killer for me. Thanks Hippy, you learn something new every day.

Well, might throw in the towel for OTA programming, it's way over over my head and not doable unless Goey wants to bring out a kit ;)

Cheers
 

Goeytex

Senior Member
@Jondo

I won't be bringing out a kit. But I may set the project back up in the lab and add some improvements. Then post schematics and code so that anyone with basic skills could replicate. I am old and tired, so this could take a while.

Goey
 

manuka

Senior Member
Agreed! However best keep in mind my original post related to educational end users who want across the classroom wireless operation that "just works" OTB (out of box).

I've pondered diverse modern approaches & offerings (BLE, BT5, Zigbee etc) but -rather than reinventing the e-wheel -also checked forum insights from ~10 years back on the original PICAXE friendly XRF/URF/ERF modules.

Surely the design,testing & brain power put in by Ciseco (& presumably Rev.Ed ?) has not been lost ?

The super chatty "Ciseco" (Miles Hodkinson) suddenly ceased Forum posting in 2012 -well before Ciseco PLC itself sadly shut up shop. I'd also significant 1:1 email with him & evaluated samples. Much of his then coverage related to the versatile CC1110 based XRF (of ~km ranges which modern LoRa modules now easily better), but valuable AT etc insights are discussed. Stan.
 
Last edited:

hippy

Technical Support
Staff member
Surely the design,testing & brain power put in by Ciseco (& presumably Rev.Ed ?) has not been lost ?
Lost or forgotten probably. AIUI, Ciseco was entirely responsible for hardware and firmware design, implementation, manufacturing and programming, and retained all rights to that, Rev-Ed merely tested, offered suggestions, produced the related Wizards and documented the How To for the PICAXE. And of course sold those Ciseco products through the online shop when they were available.
 

Goeytex

Senior Member
If, and this is a big IF, I resurrect this project, and come up with with good working prototypes, I will need a few dedicated testers that can test and evaluate and that will not leak the code or design files until project is completed. I don't want my name associated with stuff that doesn't yet work as expected. Testers will need to be knowledgeable in electronics and have the ability to provide clear and concise feedback and will be willing to spend a few bucks or a few quid on RF modules after I get good working prototypes that support all current Picaxe chips. I cannot afford to provide them.

I am not interested producing a commercial project and dealing with the cost of FCC / EU testing and Regulatory Approval as I doubt the cost of development will ever be returned in commercial sales.
But I still want to use FCC certified RF modules if available and not too pricey .

I wanted to try the Microchip Lora RF modules ( RN2903/2483) but due to the current chip shortage none will be available until late 2022. That leaves 2 or 3 Regulatory-Certified options from either Taiwan or China (Reyax/Seeed/Ebyte) that may be Ok. I think I like the Reyax stuff better partially based upon simplicity, and better documentation than the others and may try these first, however I am open to ideas.

If all goes well, what we will have in the end is a bill of materials, schematics, code, building instructions and a user manual. All open source.

Goey
 

manuka

Senior Member
I'll put my hand up for this admirable venture, although -much as I love it - am somewhat wary of LoRa complexity issues if your choose that technology. It's massive ranges could surely make LoRa an overkill for nearby/classroom OTA needs?

I've diverse links with Asian e-firms (especially Dorji) & our NZ/China free trade agreement may well give e-sourcing benefits.

In any case ensure modern superior "6 a side" SX126x based Semtech RF cores are considered. Semtech's original LoRa modules were "7 a side" SX127x based.

FWIW my OTA thoughts initially tended 10s-100s of metres with BLE. Most NZ classrooms are BYOD (especially Chrome) & Windows PCs are increasingly rare. My local 500 student elementary school only uses Win PCs in offices/admin. !

Stan.
 
Last edited:

hippy

Technical Support
Staff member
My approach would be Wi-Fi. Something which can connect to a router, convert the stream it receives to TTL RS232 for the PICAXE, and pass back what it receives.

The PC-side could be done entirely in software meaning only one bit of kit per PICAXE, and that kit could control more than one PICAXE.

Or the same kit could connect to a PC via USB or serial, connect via a router or act as an Access Point for the PICAXE-side kit.

Configuring the kit, either side, can be done by plugging it into USB and having it appear as a serial device, programmed either by a Wizard or a terminal emulator.

It seems to me the first question to answer is which or what particular problem one is intending to solve, what the primary use case is.
 

manuka

Senior Member
An interesting approach, although short on hardware details (& "break" requirements ?). The then classic & large HC-06 BT module is used- BLE is now superior in power consumption & range ( & is also inbuilt in many modern devices).
 

Attachments

PhilHornby

Senior Member
An interesting approach, although short on hardware details (& "break" requirements ?). The then classic & large HC-06 BT module is used
He did say it worked though :unsure:

I've remembered why I didn't try it for myself...although I have loads of HC-05's which are physically the same as the HC-06, they run different firmware.
 

steliosm

Senior Member
HC-05 can act as a slave device only. HC-06 can be either a slave or a master. It would make sense to use a HC-05 module on the target Picaxe and connect from a laptop having a Bluetooth adapter. This will create a serial port on windowstaht you can use to send data. Also, you need to remember that the pins on the HC-05 are 3v3.
 

PhilHornby

Senior Member
HC-05 can act as a slave device only. HC-06 can be either a slave or a master.
It's actually the other way round!

I did quite a bit of work with the HC-05, before finally giving in and realising that the HC-12 was a far better 'fit' for my project.

Queries on the forum regarding the HC-06 made me realise that, not only is the functionality different, it has lots of other subtle differences in the command interface. (So my "words of wisdom" were of little use in solving their issues :( )
 

Goeytex

Senior Member
I read the pdfs provided by guydu99 in his Bluetooth thread. Seems he kinda stumbled upon a way to do a download via Bluetooth. However, He clearly says he does not know why it works and cannot completely explain his method. Breaks are not handled, and it requires extra code in the target device. It also requires special "port- splitting" software among other things . If there is an error/ or lost connection during programming, the target can no longer be programmed wirelessly, and will need to be re-programmed normally before another wireless attempt can be tried.

While it does show that wireless programming can be done with Bluetooth, it does not address the gotchas involved with Break handing and will most likely not work in many programming scenarios.

As I see it, Break handing is the biggest obstacle to overcome. Whether with Bluetooth or any other wireless method.
 

Goeytex

Senior Member
@stan74

Don't know why LoRa would be overkill for a classroom. The "massive ranges" can be easily reduced by setting the TX power on the modules to something like 0 dbm. My main objection to LoRa is the cost, not the range. I see the range as a huge benefit in other possible use cases. In any case the TX power is adjustable.
 

steliosm

Senior Member
@Goeytex I also had a look at his documents. Couldn't figure out why he needs extra code in the target Picaxe. As for the serial port routing/splitting I think it has to do with monitoring the traffic.

In my opinion Classic Bluetooth (using SPP) might be the best way forward, given the number of devices supporting this kind of connection. Even the Raspberry Pi has support for BT connections.
 

hippy

Technical Support
Staff member
@Goeytex I also had a look at his documents. Couldn't figure out why he needs extra code in the target Picaxe.
I think that is code which ensures the PICAXE is in a state so it will handle the Break Signal Download Initiation, will make sure download isn't locked out by SERRXD, SERIN or anything else, will be ready for the Break Signal.

As for the serial port routing/splitting I think it has to do with monitoring the traffic.
It looked that way to me though I was not sure whether it is also used to kick-start a download, put the PICAXE into a state where it will better see the Break Signal Download Initiation.

If not carrying an actual Break Signal over the link, one ends up having to rely on the PICAXE thinking it saw a Break Signal and that's very hit and miss.

There are two ways to improve the chances that the PICAXE is ready for a download; ensuring it will be expecting a download ( that extra code ), and getting the PICAXE to that code ( via a split serial link and an additional terminal emulator ) before an actual download is initiated. Downlaoding then becomes a two-step process; "prime it for download" then "do the download".

I think that is what is being done here but I may have misunderstood. It would work but it is rather inconvenient to use and not at all easy to configure.
 

Goeytex

Senior Member
The Picaxe can easily be tricked in to thinking there is a download. I did this with two intermiate microcontrollers. One between the PC and the Host RF device and the other Between the remote RF device and the Target Picaxe.

The "Host" micro controller( Picaxe or Other) waits for a break "low" from the Program Editor. If it is > than 5 ms then is is a break. It then sends a byte to the to the RF device that is received by the remote RF and then to the remote intermediate Micro. IF the code is for example 0x55 this tells the Remote microcontroller to Set the target Picaxe Serrin Pin Low to simulate a break. It could also reset the target target by removing power to the target Picaxe simulating a hard reset. After the Target Picaxe Responds with $A5/Firmware Rev, Serial comms proceed normally between the Host and Remote until programming is complete

The intermediate micro-controllers act as serial repeaters. This worked nicely with the LC2000 modules and may work with HC-O5/ HM-10 Bluetooth. But if Bluetooth is used the built in Bluetooth on a laptop could not be used, It would have to be an external module that included the intermediate micro-controller between the USB/TTL adapter ( Axeo27) and the Bluetooth Module. I used 14M2 and 20M2 for the intermediate repeater Micro controllers. But any just about any modern micro could be used to save on cost. I am out of Picaxe chips at the moment but have Both 14M2 and 18M2 on order ( 20M2 and 8M2 are out of stock everywhere. (As are many RF modules ). However HC05-HM10 and NRF24L01 are readily available.

We cannot use 433 MHz here in US except at extremely low TX levels as this this a Amateur Shortwave band. So I think we must use either 868/915 or 2.4GHz to be somewhat legal. ( at least for prototyping on my end)

This brings me to LoRa/ LoraWan. I have not yet tested this so I am not sure if LoRa is capable of sending data at an acceptable rate with acceptable lag times to directly program a micro-controller wirelessly. There cannot be more than ~100ms between bytes or the Programming Editor will time out. If not, It may be possible to receive the data in to a large buffer and then dump it all at once to the target Picaxe ( not an ideal solution) . We shall see.
 
Last edited:

hippy

Technical Support
Staff member
The Picaxe can easily be tricked in to thinking there is a download. I did this with two intermiate microcontrollers ... The "Host" micro controller( Picaxe or Other) waits for a break "low" from the Program Editor. If it is > than 5 ms then is is a break.
That works because it is not really tricking the PICAXE; it is passing the Break over the link for the receiver to generate.

It was more a comment on the 'guydu99' solution. That is is not using microcontrollers, is a raw PC serial -> Bluetooth -> Bluetooth -> PICAXE scheme, which cannot pass Break Signalling, so the PICAXE has to be tricked into thinking it saw a Break, and that can be hit and miss.

Key to having wireless PICAXE programming working well and reliably is to have intelligence at both ends, in the RF modules themselves or by adding additional microcontrollers, possible assisted by PC drivers. Which is what you are doing, but 'guydu99' isn't.
 

johndo

Member
That's it...I'm getting the bluetooth modules out and giving it another crack...😁

Thank you for the inspiration guys!
 

johndo

Member
25015


I'm using this usb to serial adapter to connect the bluetooth modules to the pc. I have to invert the output at the receiving end using a 74HC04 hex inverter.

The experimenting continues...
 

Goeytex

Senior Member
My order of Picaxe chips arrives today. (14M2s' and 18M2's). I am still waiting on Bluetooth Modules, NRF24L01+PA modules and Lora Modules.

I just set up some DRF-1212 modules (433 Mhz). These are "half-duplex". However, the time it takes for a single byte to be sent, received and sent back falls well within the ~100 ms requirement of the Program Editor software.

So Wireless programming seems possible with these modules with some "intelligence" added. Should also be possible in the same manner with HC-12 modules and others. However 433 MHz is not legal in many areas. So consider any 433MHz efforts as Proof of Concept or (possibly for personal use in the lab at very low TX power) . Check your local regulations.

With Picaxe chips in hand later today, I will be putting stuff together very soon.

First I want to get Picaxe Wireless Programming working with these DorJi DRF-1212 modules( this week) as proof of concept . Then Bluetooth, Then NRF24L01, then Lora. The NRF24L01 modules will take the most time as I will probably need to write a new "library" for these.

I will post updates, code, & schematics as things move along.
 

manuka

Senior Member
Good work Goeytex ! Those Dorji modules are only FSK & date from ~10 years back. I worked with them to good effect (pre superior HC-12 style GFSK & Semtech's LoRa) & recall they'd very low (~1uA ) standby current - potentially handy for the remote receiver. Unsure if this translated to WOR (Wake On Radio) however ... Stan.
 

Attachments

Last edited:

Goeytex

Senior Member
Hi Stan,

Using these DRF-1212's for now since I have them on hand and they are relatively easy to set up.

I wanted to try some HC-12 modules, but it seems the only sure way to get an original HC-12 nowadays is directly from the Chinese manufacturer. There are clones (and even clones of clones) being sold, but no way of telling what you will actually get until you open the box.

In any case I have the Picaxe chips now and will get started on this tomorrow with the DRF-1212. Then Bluetooth after the modules arrive.
 
Last edited:
Top