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.
 
Top