Wireless programming ?

Technoman

Senior Member
Hi,
I have not tested the product, but for its apparent ease in programming I think the Ozobot should be convenient within a classroom. Using an optical signal through screen is giving some advantages : no cable, little risk of interference.
 
Last edited:

manuka

Senior Member
Yes indeed & the abundance of such educational devices rather prompted my initial posting. Aside from "CABLES -we don't want no stinking cables!" (to paraphrase "Blazing Saddles") such e-devices are ideal for enthusing modern youngsters!

Ozobots (first released in 2014) are now on a 2nd version. Costs for the more capable EVO version tend $$$, but cable free programing (Blockly) is/should be a breeze via BT & optical screen read. Android users report numerous hassles however...
 
Last edited:

erco

Senior Member
I like this discussion, the "optical screen read" path reminds me of the Datalink option on sold of my old Timex Ironman watches. Good for one-way communication from the PC monitor screen (CRT only, LED/LCDs didn't work) to the watch. The screen would flash crude barcodes and a phototransistor on the watch would decode the data. Worked fine, I'm sure a version tuned for LCD/LED tablets could be made as well.


 

Goeytex

Senior Member
UPDATE:

Success with the Dorji DRF-1212 Modules using 14M2's for intelligence. This tells me several things.

1) Half Duplex RF Modules should be OK.
2) 14M2's can handle the task ( Not enough I/O's on 08M2). This means that a faster non-Picaxe is not required for "intelligence" and that "firmware" can be upgraded via PE. Different RF Modules / Different Firmware.
3) No extra USB/TTL adapter is necessary. AXE027 works OK. The 14M2's handle the necessary RX/TX data inverting and baud rates to the RF modules.

Here is a crude Block Diagram. I will post schematics and code next week.


25030
 

inglewoodpete

Senior Member
UPDATE:

Success with the Dorji DRF-1212 Modules using 14M2's for intelligence. This tells me several things.

1) Half Duplex RF Modules should be OK.
2) 14M2's can handle the task ( Not enough I/O's on 08M2). This means that a faster non-Picaxe is not required for "intelligence" and that "firmware" can be upgraded via PE. Different RF Modules / Different Firmware.
3) No extra USB/TTL adapter is necessary. AXE027 works OK. The 14M2's handle the necessary RX/TX data inverting and baud rates to the RF modules.

Here is a crude Block Diagram. I will post schematics and code next week.


View attachment 25030
Great news Goeytex. Your dedication is appreciated.

...and more sales of PICAXEs for RevEd!
 

Goeytex

Senior Member
@erco

Those are the ones. DRF1212-D10. However no stock anywhere, as is the case with many IC based devices nowadays. You know, the "chip shortage" and all that stuff.. I just happened to have a few on hand, left over from a project I did in 2015/16.

I would advise to hold off on ordering (if you can find any) until I do some "worse case" testing with these. So far they seem to work really well on the bench at power level 2 ( around 0 dBm ).

For one worse case scenario, where the target Picaxe has "disconnect" enabled, I may need to add a bit of circuitry on the remote side that forces a hard reset on the target Picaxe after the break is applied and if the target does not respond in say, 1 second. If this is omitted then there will be certain cases where wireless programming will not work ( Can we live with that ?). The "cost" is an I/0 pin on the 14M2, a few more lines of code, and a couple of transistors and resistors. Feedback welcomed.

Goey
 

johndo

Member
@Goeytex

I think that would be an essential addition to the design. A couple of extra transistors and an extra pin on the 14m2, no big deal for the enormous benefits it would bring...
 

Technoman

Senior Member
@Goeytex : to simplify the PC's transmitting side, would it be possible to redirect the data, with a piece of software, from the serial port to an ordinary USB-Bluetooth adapter or to the pre-installed port?
Within a classroom with up to 15 students, using Bluetooth is possible (40 channels in BLE). What about the other solutions (DRF1212, ...)?
 

hippy

Technical Support
Staff member
For one worse case scenario, where the target Picaxe has "disconnect" enabled, I may need to add a bit of circuitry on the remote side that forces a hard reset on the target Picaxe
One well known issue with any microcontroller is parasitic powering. They may keep running if the power to the chip is disconnected but the chip gets its power through I/O pins. If they do keep running while getting that power they won't actually reset. That, plus the fact that it's difficult to control just the power to the microcontroller unless the target hardware is designed with that in mind, may mean having to disconnect the supply to the entire target.. That can mean switching quite high currents, even multiple voltage rails.

Even if not, some systems will be 3V3 or other voltages because of devices attached. One needs to deliver the correct voltage; just switching 5V may not always be appropriate.

As you say "one worse case scenario". Another can be when the target PICAXE is outputting lots of SERTXD or HSEROUT data or using DEBUG when wanting to download. There's the whole issue of communications beyond program download, running with various SETFREQ and different baud rates for sending and receiving data to the Terminal or something else.

And, while it may work point-to-point, how does it cope when there are multiple links in use, and how does one configure for that ?

None of this means some degree of solution cannot be found, that what the Ciseco set-up offered could not be matched, but it does stand in the way of simple universal solutions which work in all cases and scenarios.

Once one puts constraints on what a solution supports it becomes less appealing, less useful. Sod's Law would have it, that those who would want to use it, want to do something beyond what is supported, and it ends up not being the solution it was imagined it would be.
 

Goeytex

Senior Member
Hi Hippy,

Parasitic powering will certainly need to be addressed on target side in order for a hard reset to work. While it may be "well known" issue, preventative measures seem to be neglected by many in their circuit designs, either because they don't know, don't care, or because it seemingly has no effect until they try a hard reset, or when they remove V+ from the microcontroller and wonder why it is still running. I suppose I could provide a write up on on this as well as offer several circuit design options. I have not looked at Rev-Ed boards to see if this is addressed or not, but I suspect not. It's kinda like not using a current limit resistor on Picaxe inputs or not pulling up/down unused input pins. Known good practice, but generally ignored, even by experienced users and manufacturers.

To be clear, the goal here( My goal) is to provide proof of concept designs that can be replicated using Picaxe Chips and off the shelf RF modules at 433MHz, 915/868MHz and 2.4GHz starting with point to point and then later point to multipoint. Users ( many smarter than me) can then tweak, or modify as they desire. There will likely be a few "gotchas" as well as some requested "features" that I am not willing or able to provide or do not have the resources or skills to provide (others may). I am NOT trying to clone the mighty (but long defunct) Ciseco devices, yet I wonder why Rev-Ed has not taken up the mantle on this. Thus my current efforts.

Sod's Law may come in to play, however Goey's Law says that if you don't like it, either help to improve it or get out of the way.
 
Last edited:

hippy

Technical Support
Staff member
Parasitic powering will certainly need to be addressed on target side in order for a hard reset to work. While it may be "well known" issue, preventative measures seem to be neglected by many in their circuit designs, either because they don't know, don't care, or because it seemingly has no effect until they try a hard reset, or when they remove V+ from the microcontroller and wonder why it is still running.
I would say it's probably because most people following the Hard Reset procedure will be powering the 'whole lot' off and back on, so it doesn't usually cause an issue.

If they are not it is something to bear in mind when someone reports Hard Reset doesn't work but in my experience that's usually down to getting the sequence and timing right.

I am NOT trying to clone the mighty (but long defunct) Ciseco devices, yet I wonder why Rev-Ed has not taken up the mantle on this.
Possibly a few factors; the issue of only being useful in a limited set of circumstances, the challenge of making it more universal, the having to do it and make it work, perhaps lack of demand for having it, it not giving a good return on investment, and the problem of wireless parts used being superseded or difficult to obtain, rendering it prematurely end of life, in need of a redesign, quite a lot more work, with potential incompatibilities.

Sod's Law may come in to play, however Goey's Law says that if you don't like it, either help to improve it or get out of the way.
That's the luxury of not providing a commercial product which customers expect to work for what they want to do, who expect the supplier to make it so.
 

inglewoodpete

Senior Member
Just a thought on the potential problems discussed above.

I imagine that sending the "break" signal is treated as an out-of-band management signal in your "protocol" Goey. Would it be feasible to add another ON/OFF signal that the receiving PICAXE could use to set a spare output high or low. Depending on the actual requirements of a user project, the user could use this output to, say, operate a relay that interrupts the power supply to the target PICAXE (or anything else that might interfere with the reprogramming of the target). After further thought, perhaps a break signal sent to the receiving PICAXE could trigger this action automatically.
 

Goeytex

Senior Member
@IP

What I will try to do this weekend, is to use a transmitted break signal( a byte) that tells the Remote 14M2 to pull the serin Pin Low on the target. If the target responds within 1.5 seconds, programming commences. If past 1.5 seconds, the 14M2 will set a pin that turns power off to the Target Picaxe. An ADC on the 14M2 could be used to monitor the voltage. When below 1.0V ( caps discharged, etc), power back up while the break is still applied then wait again for the target to respond, and so on. So the Target Picaxe is not hard reset unless it fails to respond to a break after 1.5 s. I could make it longer if necessary. We have 5 seconds to get a "$A5, FIRMWARE" response from the target back to PE, before PE returns an error. Should be no problem . Feedback welcomed.

Goey
 

erco

Senior Member
@erco

Those are the ones. DRF1212-D10. However no stock anywhere, as is the case with many IC based devices nowadays. You know, the "chip shortage" and all that stuff.. I just happened to have a few on hand, left over from a project I did in 2015/16.

I would advise to hold off on ordering...
Guilty as charged, I nabbed the last one, supremely confident in your abilities. :)

FYI when they do become available again from this seller, they took my offer of $23 flat.

dorji.png
 

Goeytex

Senior Member
@erco

OK then ... You have now been conscripted to build and test some prototypes.

I will provide you with code, schematics and some instructions ... Probably on Monday.
 

Goeytex

Senior Member
UPDATE:

Coming along nicely as time permits.

To lessen the load on the intermediate 14M2's, and to mitigate the related processing delays, hardware inverters were added to each circuit. This way after the break and initial handshake are processed, the RF Module (Non Inverted Serial) can directly communicate with the Axe027 on the PC side and with the Target Picaxe on the remote side. This allows wireless programming as fast as the RF modules are capable of doing.

I am currently using 2 discrete FETS (2n7000) on each end. This works well. However, 74HCT inverters could be used as well, to both invert and to level shift. (RF M0dule is 3.3V). If I were to order PCBs, would probably use one dual inverter on each end (74HCT2G14GV).

Goey
 

hippy

Technical Support
Staff member
To lessen the load on the intermediate 14M2's, and to mitigate the related processing delays, hardware inverters were added to each circuit.
All the M2 chips have a Data Signal Modulator (DSM) which can allow an inversion on-chip independent of what else the PICAXE is doing which can save on needing additional hardware.

On the 14M2 the input is C.0 with output on C.1. The DSM is not supported directly by PICAXE Basic but can be configured through POKESFR. Untested on an actual chip but I believe this should allow C.1 to be the inverse of C.0 -
Code:
Symbol MDCON  = $FC ; SFR $39C
Symbol MDSRC  = $FD ; SFR $39D
Symbol MDCARL = $FE ; SFR $39E
Symbol MDCARH = $FF ; SFR $39F

PokeSfr MDCON,  %11000000
PokeSfr MDSRC,  %00000001
PokeSfr MDCARL, %01000000
PokeSfr MDCARH, %00000000
 

Goeytex

Senior Member
Thanks,

Looking at the datasheet, there is only 1 DSM module. This possibly allows for the inversion of only 1 signal without jumping through hoops. Both the serial output of the RF module and the serial output of the AXE-027 need to be inverted. And honesty, at this point ( near completion) I'd rather not be poking around in unsupported peripheral registers unless absolutely necessary.

The external inverters are ok for now, however this or something similar could certainly be revisited later.
 

hippy

Technical Support
Staff member
Looking at the datasheet, there is only 1 DSM module. This possibly allows for the inversion of only 1 signal without jumping through hoops. Both the serial output of the RF module and the serial output of the AXE-027 need to be inverted.
There is only one DSM but I would have thought you would only need one inversion, the other done within the 14M2, though I guess it does depend upon how you are doing things -
Code:
   |   .----.   .----.   .----.   .----.   .--------.
   |-->|14M2|-->|    |   |    |-->|14M2|-->|        |
PC |   `----'   | RF |= =| RF |   `----'   | TARGET |
   |<---O<|-----|    |   |    |<---O<|-----|        |
   |            `----'   `----'            `--------'
And honesty, at this point ( near completion) I'd rather not be poking around in unsupported peripheral registers unless absolutely necessary.
That's fair enough. I was thinking more about the next step once what you have is working. Other people will be more inclined to build something when it's a bare minimum, just a couple of 14M2 and RF modules wired together without additional components.
 

Goeytex

Senior Member
Having a 14M2 "handle everything" means that the 14M2 receives (inverted) data from the AXE027, and resends ( at opposite polarity) it to to the RF module. This (in effect) more than doubles the time for 1 byte to be sent from the PE side. The target side RF module has to do the same. Now we have more than quadrupled the time for a byte to make the round trip from Program Editor and back. This does not account for Picaxe overhead or packet handing by the RF module

By adding 2 transistors and a few resistors, the intercepting and resending by the 14M2s and the associated overhead can be eliminated. The only added time will be the packet handing by the RF module. Programming is slow enough with the wired Picaxe method at 4800 baud.

Thinking that this can be done with "no additional components" is not very realistic.

Right now we are looking at 2 NPN transistors and 6 resistors along with the RF module and the 14M2. I imagine this to be within the skill set of anyone seriously interested .
 
Last edited:

erco

Senior Member
Right now we are looking at 2 NPN transistors and 6 resistors along with the RF module and the 14M2. I imagine this to be within the skill set of anyone seriously interested .
Amen, Brother Goey! A slight increase in parts count is a one-time delay during construction, vs perpetual delays in operation. My RF modules arrived already, amazingly fast ship. No time to build yet, but this will be a great Christmas turkey project.
 

manuka

Senior Member
Good work indeed Goeytex!

Mmm -I'm now pondering any likely current drain the 14M2 and transistor intermediate circuitry may add. Quite aside from classroom work (which was my first thought of course) I've experiences of PICAXE circuitry in monitoring locations only drawing microamp level currents between readings.

Those Dorji modules are admirable energy misers & if this 14M2 interface remains at much the same level all should be OK. However if the interface is a bit of a "power hog" then situations arise where larger batteries or solar panels etc will be needed to handle the load.

RF sensing WOR (Wake On Radio -also known as WUR = Wake up Radio) features are available in some wireless data modules -CC1101 etc - whereby the receiver briefly "sniffs" the channel. Otherwise a simpler SLEEP may be needed to eventually respond to a sender firing "machine gun" style.

I'd no experiences with the CISECO offering from a decade back but assume such overheads were then considered. Did anyone work with them? Hippy?

Stan.
 
Last edited:

hippy

Technical Support
Staff member
I'd no experiences with the CISECO offering from a decade back but assume such overheads were then considered. Did anyone work with them? Hippy?
I did a little work with them but don't recall doing any testing regarding current consumption, sleep modes or wake-up.

I believe they were expected to be used in permanently powered projects. I have no idea how their programmed firmware would have been controlling the RF side of things or how suitable they would have been in low-power projects.

I have to admit that I hadn't really given it much thought. The requirements for wireless programming and wireless data communications may need different approaches.
 

hippy

Technical Support
Staff member
Right now we are looking at 2 NPN transistors and 6 resistors along with the RF module and the 14M2. I imagine this to be within the skill set of anyone seriously interested .
Amen, Brother Goey! A slight increase in parts count is a one-time delay during construction, vs perpetual delays in operation.
My main concern was that everything extra which is needed can be something which puts people off. That won't be a hindrance to those who are determined to have it but can reduce the audience which might be interested in it. A few extra components shouldn't be an obstacle but people are fickle things and for some they will be.

I suppose I tend to look at things from a 'maximising take-up' perspective and that is not necessarily applicable here.

I am not sure through-put delays would be that problematic but they may be. PC apps are often put to sleep for 20ms or so if they can't immediately continue, and will sleep that long regardless of data arriving before they wake. In such cases though-put should be the same providing the data arrives before that sleep period ends. If data hasn't arrived within the period another sleep period will be entered and that will halve through-put, double transfer times. That is very noticeable, far from desirable. It would depend on the OS and one would have to try it to see.
 

Goeytex

Senior Member
It should be possible to put the Picaxe(s) and RF modules to sleep and then occasionally wake-up to check if a program download has been initiated.
Since the Break lasts 5 up to seconds waiting for a response from the target Picaxe, we should be able to have the Picaxe and RF devices "sleep" most of the time. Something like.... Sleep for 100 ms, wakeup and test if break is active, if active enable RF Module and start programming, If break is not active go back to sleep and start over. So sleeping about 99 percent of the time.

The power consumption should be quite low if the external circuitry is well designed.
 

Goeytex

Senior Member
To be clear.

The hardware inversion is only necessary on the PE side because the AXE027 inverts the data to "idle low" and the RF Module (DRF and all others) require Idle high ( non inverted). This hardware inversion could be eliminated if we abandon support for the AXE027 and opt for a normal USB/TTL adapter that does not invert the data to the non-standard idle low polarity ).

My strategy was to maintain support for AX027 as I am guessing that most users will have one and to kinda "keep it in the family". The same strategy was used when selecting the 14M2s for intelligence. However it could just as well be done and done even better and faster by using a more capable PIC programmed via another platform. Something like a PIC 18F04Q41. Great for a commercial offering but not so great for for the average Picaxer who would then need to have a PIC programmer and the skill set to write/modify code in another language to update the firmware.

There is a method to my madness ... I hope.
 

Goeytex

Senior Member
I just received some (hopefully ) original HC-12 modules, as well as as some AT-09 (HM-10 Compatible?) Bluetooth modules. As soon as I wrap up things with the Dorji DRF1212 stuff, I will post the code and schematics, then move to HC-12.

HC-12 code / schematics should not be much different from the DRF1212, but the HC-12s should provide significantly more range where 433 Mhz is acceptable/legal. I think that 10 dBm may be the legal limit for 433MHz in Europe while it is much less in the USA.

Have a look at these guys .... and how the fake modules gave little range while original modules worked as expected.

 

manuka

Senior Member
More good news ! Perhaps an issue is that the HC12 Tx rating of 100mW is too powerful for the 433 MHz ISM band. However it "can" be decreased & even readily set to other UHF frequencies that may be legal in particular countries. Fellow Kiwi Rob Rozee even wrote a configuring GUI => https://www.thebackshed.com/forum/ViewTopic_mobile.php?FID=16&TID=8246&PID=0&LastEntry=

I've not used the HC-12 USB dongle (Forum => https://picaxeforum.co.uk/threads/configuring-hc-12-usb-module-slightly-ot.30373/ ) but it may have benefit at the control end as it just plugs into the sending PC.
 
Last edited:

Goeytex

Senior Member
The HC-12 is generally advertised at having an Si4463 IC which can cover from 142Mhz to 1050Mhz. However, they actually ship with an Si4438 IC, which only covers from 425-525 MHz.

If you happen to get one with an Si4463 IC, it could be configured for 868Mhz or 915MHz bands, but odds are that the antenna matching components will be for 433Mhz, so the performance/range will be significantly degraded.

You may find a supplier somewhere that actually uses an Si4463, but it will most likely be a fake/clone and the antenna matching will be for 433Mhz

Also, looking at the customer reviews on various sites, it seems that HC-12s can have different firmwares, likely depending on what chip is actually used . As I understand it, HC-12 modules with different firmwares cannot communicate with each other, even when set up to the same frequency/ baud rates. (Based on customer reviews at Banggood)

www.hc01.com is the originator of the HC-12 and may have used the Si4463 at one time, but now they use Si4438. I could probably get more info but I cannot get Google Translate to translate this Chinese site into English . If someone knows how, please let me know.
 
Last edited:

manuka

Senior Member
Assume you mean this? The 1,2,3 simply relate to ID of genuine HC-12.

Although I was an early HC-12 user magnificent LoRa rather took my fancy from about 2015 & I've not kept up with the the fake saga. However I recall new "fakes" had crystals off spec. so that (on the 433MHz ISM band) a true 433.400 MHz on the originals was actually 433.437 MHz. Same brand fakes COULD work together but mixing old & new was suspect as channels were 37 kHz out.

Extra: By chance my adult daughter,although not e-technical, is fluent in Mandarin (both written & spoken) & "may" be able to assist with translations.
 

Attachments

Last edited:

Goeytex

Senior Member
Update:

Sorry for the delay ...

I had some pressing matters. Got back to it yesterday and exterminated a couple of minor, but annoying bugs.

I have wirelessly programmed a 14M2 well over 50 times at short range with no errors. I will crank up the power and do some range testing, probably Monday or Tuesday.

The wireless programming speed is acceptable at about 2 times the normal wired speed.

The DRF-1212 modules need to be programmed/configured for 4800 Baud and an air data rate of either 10k bps or 20K bps. 20K will give a bit more speed, 10K will give more range. The TX power level also needs to be considered and set appropriately.

These DRF-1212 modules can be programmed 3 ways:
1) By using a Dorji supplied "DAC-02" and the "DRF Tool" application or
2) With a Terminal Application and USB/TTL Adapter
3) Using a microcontroller/Picaxe

I used the DAC-02, but think it is probably best to provide code and / or instructions for using the terminal app ( I like CoolTerm) so that folks that don't have a DAC-02 won't be up a creek or have to decipher the "datasheet" . The modules only need to be programmed once as the settings are retained in the module's EEPROM. ( The DRF Tool App does not appear to work with Windows 10 unless compatibility mode is set to Win 8).

So I am writing up the instructions now as well as preparing the code and schematics for publishing/peer review.

Attached is a 'preview' of the exact circuit that I am using for testing. This is the remote/target side only and there will likely be an updated version in a few days that will include the Host Side.

Note that the 2 transistors invert the already inverted data to and from the AXE027, and also act as tri-state buffers to "disconnect" the AXE027 from the RF modules. A more detailed explanation will be forthcoming .


Goeytex
 

Attachments

PhilHornby

Senior Member
As I understand it, HC-12 modules with different firmwares cannot communicate with each other, even when set up to the same frequency/ baud rates. (Based on customer reviews at Banggood)
I thought we'd ascertained it was because some of them have dodgy (ie not 30MHz) crystals?
As per this sequence of posts: https://picaxeforum.co.uk/threads/hc-11-and-hc-12-transceiver-modules.28893/post-319060
www.hc01.com is the originator of the HC-12 and may have used the Si4463 at one time, but now they use Si4438. I could probably get more info but I cannot get Google Translate to translate this Chinese site into English . If someone knows how, please let me know.
I turned my firewall off for long enough to have a look at this (I have a country block for China :( ) ...

The site appeared -eventually- in English (mainly). It turns out that Microsoft Edge had "Always translate pages from Chinese (Simplified)" enabled.

I can't find any mention of the Si4463 in the English 'user manual' @ http://www.hc01.com/downloads/HC-12 english datasheets.pdf

There is a photo of the module and the RF IC bears the legend: "44382A" / "C01ARO" / "204?1" if that means anything to anyone.

(I photographed one of my own - and the legend is slightly different: "44382A" / "C014VS" / "2011".

25062
 
Last edited:

papaof2

Senior Member
"44382A " does start with "4438" so that might be a valid assumption ;-) "2011" is either the 4 digit year of production or it could be year "20" period "11" - or the reverse "CO14V5" might be the firmware release and that it's Version 5?
 

PhilHornby

Senior Member
"44382A " does start with "4438" so that might be a valid assumption ;-)
Sounds plausible - so I thought I'd have a quick look at a much older one ...
It bears no resemblance!

25063

But does contain the string "4463" ! (More obviously, if you rotate the picture :D )
 
Last edited:
Top