Wireless programming ?

AllyCat

Senior Member
Hi,
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.
The above appears to confirm what Goey said in #75. ;) And the third line looks very like a date code: Year (YY) and Week Number (WW) from the "1631" (August 2016, version 1B?) of the "much older" picture and "2011" (March 2020, version 2A?) of the more recent.

Cheers, Alan.
 
Last edited:

papaof2

Senior Member
No need to rotate - I learned to read what was on the teacher's desk when I was in elementary school - been doing that for decades ;-)
 

Goeytex

Senior Member
Hi,

The current code and circuitry ( above) does not support hard resetting of the target Picaxe in the case where the Target has code has "Disconnect" enabled or where there could be a long pause or other case where the Target does not respond to a break. This can easily be taken care of by adding a PNP transistor to the Target side circuit and adding a line or two of code. I will add this later as time allows.

Note that I used 3.3 V as the power source for the Picaxe Chips and the DRF 1212 modules. This is because I am lazy and did not want to take the time to include level shifting to the DRF Module RX input and to add a 3.3V source for the DRF Module. This can also be rather easily accommodated if the Picaxe(s) must operate at 5.0V

The above diagrams and code work well and are adequate to demonstrate Wireless Picaxe Programming using a DRF1212D10 RF module. This should also work with an HC-12 RF module with some minor changes.

Goey
 

Goeytex

Senior Member
HC-12 initial testing shows that it takes ~33 ms for a single byte to to be sent by one module and received by another. This is with the air data rate set to 4800 baud (same as with the DRF-1212). So that would be ~66 ms round trip for each byte plus the time it takes the PE and target to do what they do. So around 70 ms.

If the Program is 2.5K bytes then that is approximately 2500 * 70 ms = ~175 seconds. Compare that to the DRF-1212 at ~30 seconds.

The "Time of Flight" can be reduced by increasing the air data rate. However this would require the 14M2 to receive the databyte from PE at at 4800 Baud, then re-transmit it at 19200 or 38400 ( or higher) to the RF Module. And the same on the target side. This would, of course, reduce the range, but is doable.

So it seems that the packet handler in the HC-12 works differently from that in the DRF-1212. This could be the difference between FSK and GFSK or it could be the HC-12 firmware and how it handles 1 byte packets... ie. how long does it wait for more bytes before sending a packet with only 1 byte?

175 seconds is agonizingly slow to me. Not worth the effort IMO.

The times I indicated for the HC-12 are only when a single byte packet is sent. This is how the PE software works ... One byte at a time. Streaming data works nearly transparently at the full 4800 baud rate once the first byte is sent. So for other uses this module seems great. But probably not a good candidate for Picaxe Wireless Programming.

It is looking like either Bluetooth or NRF2401+ will be the best overall solution.

Feedback ?

Goey
 

johndo

Member
Goey,

Mate, what an excellent piece of work! Can't wait to build your circuit and test...

I've decided that Bluetooth would probably work best in my situation, seeing that its only about 5 meters from my computer to the current project in use and I like the idea of the sort of "secure" system you can implement with the Bluetooth modules. I'm finalizing my design for my Watertank project and will integrate your wireless programming circuit onto the final board. Would people be interested in a PCB to build their wireless programming module onto? I'm no expert designer but would be happy to knock something up for the forum.

Cheers,
Kurt
 

Goeytex

Senior Member
Bluetooth:

I ordered and received a pair Hiletgo AT-09 Bluetooth Modules. These are supposed to be HM10 compatible, but they are not. These have different AT commands (some of which do not work). Further research indicates that these are clones of the MLT-BT05 which itself is a clone of the HM-10. So a clone of a clone. Go figure. The firmware/ settings of these Hiletgo modules do not even match the MLT-BT05 datasheet. For example the baud rate settings.

In any case these modules can connect to a phone, but cannot connect to each other when one is master and the other is slave. I have found Youtube videos where HM-10 modules can be connected (paired) to each other and where 2 HC-05's can be paired to each other. But nowhere to be found is any video or tutorial that demonstrates 2 AT-09 modules paired to each other to allow comms between 2 Arduinos (microcontrollers) .

If anyone can find a link or other information that shows how 2 "AT-09" modules can be paired please let me know.

In the meantime I have ordered some original HM-10 modules and some HC-05 modules.

Goey
 

mushroom

New Member
Phil Hornby. Just saw your pics in posts 78 and 80. I haven't kept up with versions of the board but in the past have found these great, easy.
The pic in post 78 has a crystal with 30,000 on it and I understand this to be a fake. The pic in post 80 has T300 on the crystal. These are the genuine boards. Warning, often adds on Ebay show a pic of the genuine board but the fake is delivered.
 

Goeytex

Senior Member
Phil Hornby. Just saw your pics in posts 78 and 80. I haven't kept up with versions of the board but in the past have found these great, easy.
The pic in post 78 has a crystal with 30,000 on it and I understand this to be a fake. The pic in post 80 has T300 on the crystal. These are the genuine boards. Warning, often adds on Ebay show a pic of the genuine board but the fake is delivered.
@mushroom

I think you have that reversed. The crystal with 30.000 and the HC01 logo on it are indicative of an original.
 

Goeytex

Senior Member
UPDATE:

Hippy brought up the idea that some users may be more likely to build something if it did not require too many extra components. Stan inquired as the to current drain added by pullups on the transistor inverters. Both of these are relevant.

So I removed the transistor inverters and re-wrote the code so that the 14M2 does all the work. This works ok and simplifies the build by eliminating 2 transistors and 6 resistors ( on each side). It also eliminates current draw related to the pullups.

However, it adds significantly to the time it takes to complete a wireless download. If you don't mind waiting minutes for a wireless download to complete this might be a viable alternative solution. I will eventually post the diagrams and code for this option.

This "best" option IMO would be to use an Inverting 2 input Tri-State buffer (74LVC2G240) and is what I would use on a commercial product. But these are SMD only and require an adapter to breadboard and good eyesight to hand solder.

Goey
 

manuka

Senior Member
I support simplicity & for the likes of "a weather station on the barn roof " the increased transfer duration should not be too concerning. What typical current drains (both now & originally) are you seeing ? Stan.
 
Last edited:

Goeytex

Senior Member
@manuka

I have not done yet done any real power consumption tests using the DRF-1212. The code will need to be modified to initially put the RF Module into sleep mode. The 14M2 will also go into sleep mode. An interrupt will be used to wake up the 14M2 when PE/AXE027 sends the "break".

The DRF-1212 draws 2.5uA when in sleep mode. 2.5uA * 3.3V = ~ 8 micro watts. Not sure about the 14M2. The power consumption should be in the micro watt range when there is no download taking place. We shall see when I get to that.

Taking advantage of sleep modes with both the 14M2 and whatever RF device is used should make power consumption of little concern. If I do it right, battery operation should not be a problem.
 

Goeytex

Senior Member
@manuka

Current Drain ( Idle - waiting) was about 8ma before I removed transistors, and rather strong Pullups. After removal and implementation of Sleep the Idle current ( No Download) is less than 1 ma ( My power supply says "0"). I will take accurate readings later.

When out of sleep mode ( No Download) the idle current is ~6ma. (Picaxe awake. RF Module in receive Mode 1.)

I could not use an interrupt to wake the 14M2 as that is not supported. So I used "Sleep 1" in a loop where the state of the PE Serout is tested every 2.2 seconds. Since the Break from PE stays on for up to 5 seconds this works ok.

At another time I will put the transistors back in and test with and without sleep. But I imagine that about 1-2 ma were saved by eliminating the transistors/ pullups.
 

manuka

Senior Member
Those values look very satisfactory & should be readily handled (outdoors) by a small PV panel. Looking forward to seeing your code & circuitry.
Take a break for the festive season !
Stan. in summery NZ
 

Goeytex

Senior Member
Referring back to Post # 94 ....

I have abandoned this method. It is simply too slow and I jumped the gun on declaring it to work ok. It works ok on the host side but not on the target side. The Target side 14M2 "serin" simply cannot keep up with target Picaxe". The target Picaxe responds too fast to a data byte sent by the 14M2 for the 14M2 to turn around and capture the response via serin. The data byte is already being sent by the target before the 14M2 serin can catch it, so the byte is missed. Hardware signal inversion will be necessary to take this load off of the 14M2.

I thought maybe hserin could be used if it were remaped to Pin C.2 by writing the APFCON register with pokesfr, and then inverting hserin with hsersetup, but the 14M2 (PIC16F1825) does not support inverting of hserin, only hserout. This would require a 20x2 and I am not going there .


New genuine HM-19 Bluetooth (BLE 5.0) modules arriving tomorrow. These are supposed to do 30 meters indoors and up to 200 meters outdoors ( Line of sight) . We shall see.

Goey
 
Last edited:

AllyCat

Senior Member
Hi,
...but the 14M2 (PIC16F1825) does not support inverting of hserin, only hserout.
Yes, Microchip "forgetting" to put a programmable XOR gate on the HSERIN (UART) input pin is a real annoyance. However, the "Data Signal Modulator" and/or the ("Analogue") Comparator(s) are available on all M2s, via POKE/PEEKSR commands. The DSM has little flexibility in its use of pins, so generally the Comparators are more useful as a hardware inverter, if you do have a few "spare" pins.

Note also that all M2s have a "timing issue" with HSERIN if a second byte is received too soon after the first. However, this is easily solved by reading the buffer directly with two PEEKSFR commands (one to read the status flag, the other for the data byte). Various threads and code snippets have documented all these issues, if required.

Cheers, Alan.
 

manuka

Senior Member
Sorry to hear of the "abandonment" after such sterling strenuous slaving. Fingers crossed for BLE & HM-19 !
 

Goeytex

Senior Member
To Be Clear ...

I have only abandoned the method where the 14M2s do the signal inversion. With hardware inversion by either transistor or IC ...the DRF1212 works great.

With that method I have added a P-Channel FET as a power switch to the target Picaxe. This does a hard reset to initiate programming, assuring programming under worse case scenarios ( Disconnect, long pauses, etc.) I got 100 of these Si2301 FETs for 8.95, along with some SMD to DIP adapters to allow breadboarding.


Goey
 

johndo

Member
@Goeytex

I've been experimenting with some bluetooth modules (HC-O6) and wanted to verify baud rates. I note in your code that the 14m2 is monitoring the response code from the target picaxe at 4800 baud. Is this what both the modules should be set to? The "regular" usb to serial cable is set to 9600. Does the programming editor commandeer the port and set it to 4800?

Cheers, Kurt
 

Goeytex

Senior Member
@johndo

Picaxe programming requires serial data at 4800 Baud ( Inverted polarity). Most all serial enabled RF devices use Normal Polarity. Why Rev-Ed used inverted polarity, I have no clue...

In any case the PE sends/receives programming data at 4800 baud( inverted) as does the target Picaxe. So this inverted data must be translated to non-inverted to communicate with the RF-module.

Your HC-06 Modules can only operate as slaves so you cannot connect( pair) these together. One needs to be a master. ( HC-05).
HC-05 can be either master or slave.


Goey
 

Goeytex

Senior Member
Great looking specs for that MOSFET. I'll get a few in my next parts order!
I took a chance on these, suspecting they might be fakes with poor/off-spec performance. However, they seem to be the real deal. I have had no issues with these so far. And since my cataract surgery in November I can now see well enough to hand solder SMD stuff again. So I am back in the game as far as that goes. I just soldered up a few of these for this project. ===> 74LVC2G240DP

Goey
 
Last edited:

Goeytex

Senior Member
UPDATE:

I am about to rap up the DRF1212 Version of this project. New schematics and code will be forthcoming (after New Year's) . I will also include some screen shots from Saleae Logic to help show how the Picaxe Programming Protocol works. It is really quite simple, but not very efficient since it is done in 512 byte blocks.

What I mean by that is if, for example, a Picaxe program is only 70 bytes, it will first send the 70 bytes one at a time, then it will send 442 bytes one at at time with a value of "0" to fill the rest of this 512 byte block of flash memory. If the PE/Firmware was a bit smarter, it would know that the program was 70 bytes and would only send the relevant 70 bytes to the target, then internally write the ''0's" instead of sending them 1 byte at a time from the PE to the target.

This is also interesting as the flash memory page size of a 16F1825(14M2) is 64 bytes. With this family of 16F PIC's, flash memory must be erased/written in 64 byte blocks, so internally the PE/Firmware is configured to self-write (via the EECON registers) a minimum of 8 "erase blocks" of flash memory. At least for a 14M2 or 20M2. 18F PIC's may be a bit different( X2 chips)

Also, I will create a new Picaxe Wireless Programming thread in the User Projects section of this Forum as we move forward, and hope that at least a few of you have the time and resources to replicate my efforts and provide feedback / peer review.

For those that are interested, it will be helpful (but not absolutely necessary) to have a cheap 8 channel logic analyzer that can operate with Saleae Logic (1.2.29) and the latest version of LTSpice ( For schematic drawing)

DRF1212D10 are currently available here >>> DRF1212 on Ebay

PS: The HC-19 Bluetooth modules are here !

Goey
 
Last edited:

johndo

Member
@Goeytex

Thank you for the clarification RE: picaxe programming baud rates and inversions. I always thought it was 9600.

My apologies but i have incorrectly named the modules I'm using. They are correctly
MLT-BT05 4.0 which i think roughly translates into HC-05. I have successfully paired them as a master/slave configuration.

I'm using a "normal" usb to serial converter (idle high CH-340) on the host side so would not need an inverter, just the on target side when using blutooth modules???

Once again Goey what you have done here is very clever...
 
Last edited:

Goeytex

Senior Member
I'm using a "normal" usb to serial converter (idle high CH-340) on the host side so would not need an inverter, just the on target side when using blutooth modules???

That sounds about right ... You will only need to invert the data going to and from the target Picaxe
 

johndo

Member
@Goeytex

Success!

I've managed to wirelessly program a 20x2 picaxe with 3894 bytes. A few modifications to your code using two 08M2's and two MLT-BT05 4.0 bluetooth modules as Master/Slave configuration. Download takes about 2m40s, so not ideal if your in a hurry but well worth the convenience!

Thanks again for your great work Goey!!!

Cheers,
Kurt
 

Goeytex

Senior Member
Excellent.

As you have realized, the general method is quite simple.

The longer programing times are a result of how long it takes for the RF device to process and send/receive a single byte packet. The RF Device must get the byte from the PE, then wait to see if more are coming, if no more bytes come after a predetermined time it builds the packet and transmits it. This was about 15 ms for the DRF1212 and about 33 ms for the HC-12 just on the TX side. The PE adds its own delays as well, so it all adds up.

Normally (wired), the time between bytes sent by the PE is ~16ms. However with the DRF1212 this increases to ~52ms.

Doing the maths it seems that your Bluetooth device reduces this to about 40ms per byte, likely as a result of the increased over the air baud rate. So a significant speed increase over the DRF1212 .

Programming is already "slow" with a Picaxe given the low baud rate (4800) and the inefficient/clunky byte-by-byte method for sending the data. However the 52ms per byte is agonizingly slow for working on the bench. And while it does eliminate the wires between the PE and the target, folks will soon get annoyed with waiting for programs to complete downloading. So not much value in this use case IMO.

In a classroom of 15 work stations it would take ~28 seconds to program each station with a 512 byte program ( the minimum ) with the DRF1212 for a total time of 420 seconds ( 7 minutes) . With the MLT-BT05 4.0 this would be reduced to ~21 seconds each for a total time of ~ 5 min 15 seconds

However, large programs could take several minutes per station.

My guess is that a NRF24L01 'might' be faster. This is because the packet handler can be configured to send the byte immediately via whatever helper chip is used. In this case it would not be a Picaxe 14M2 but rather a PIC programmed with ASM, C, or GCB that can quickly convert Serial data to SPI. The end user would need a PIC programmer to load the hex file.


Goey
 
Last edited:

johndo

Member
@Goeytex

Your humility is admirable, yes the general principle is fairly basic but if it was that easy to implement the solution would have been all over the forum years ago....

I have measured the time between bytes (I hope this is the correct method) as being between 39ms & 53ms, this varies over the span of the download. I will be trying some different bluetooth modules to see if there is any improvement in transmission rates.

Your observation about slowness on the bench is probably correct, wireless programming would likely only be practical for remote programming if the target picaxe is inconveniently placed up a tree for example.

Kurt
 
Last edited:

johndo

Member
@Goeytex

Update!

Tried some other bluetooth modules I had laying around and the results are very disappointing! They were advertised as HM-10 but it turns out they are fakes.

The HM-10 modules report as MLT-BT05 V4.4 so an updated firmware than my other HC-05's which report as MLT-BT05 V4.0.

Hardware is totally different between the modules... HC-05 ( MLT-BT05 V4.0) on LEFT and HM-10 (MLT-BT05 V4.4) on RIGHTHC-05 LEFT HM-10 RIGHT S.jpg

Time between bytes with the HM-10's is a very consistent 100ms and total download time for 3894 bytes is a blistering 7m17s!

Would be very interested in the results with your genuine HM-19 modules when you have the time to post Goey...

Cheers,
Kurt
 
Last edited:

manuka

Senior Member
Dauntingly slow times indeed... I wonder how these compare with the original Ciseco wireless modules from a decade back? Anyone ( Hippy ? ) ?
 

Goeytex

Senior Member
The Ciseco modules were probably faster. At least faster than the 100 ms reported by Johndo with the fake HM-10's. Ciseco modules had the benefit of a non-Picaxe chip for Firmware ( Compiled Code) and the ability to write custom firmware for the RF IC Chips that possibly minimized packet delays when sending/receiving bytes 1-by-1 (as required by the Picaxe Programming Protocol). The slowness is party due to the RF device's packet handling, and partly due the inefficient Picaxe Programming Protocol. I am fairly sure that REV-ED did not have wireless programming in mind when they developed the firmware/ programming method. How could they have known way back then? But as the old, worn out cliche goes. "It is what it is"

My guess is that the Ciseco modules could possibly have done it somewhere around 25- 30ms per byte or even faster by implementing "fixed packet length mode" and setting it to 1 after the initial handshaking. This means as soon as 1 byte is send to the TX Fifo it is immediately transmitted. This is generally not possible with most "UART Enabled" RF modules like the DRF1212 and HC-12, since this level of configuration is not supported. But probably doable with most front end modules that support fix length packets and where the developer integrates the microcontroller and firmware. .

I am hoping that the HM-19 modules will do better when I get to them. If I recall, the Inhaos LC-2000PA modules were not too shabby and I may have to revisit these as they will be available again sometime in March (per Inhaos).
 

johndo

Member
Yes the programming is relatively slow compared to using the cable method but considering the great availability of the HC-05 bluetooth modules (and they're cheap) which can do a FULL download in just over 3 minutes, is it really worth sourcing more exotic, expensive and harder to find modules? Just a thought...With the exception of your HM-19 modules of course Goey...😁
 

Goeytex

Senior Member
Hi Johndo,

Front end modules are typically cheaper than UART enabled modules, since they do not incorporate a micro-controller that sets up the registers and retains the settings in EEPROM, as well as translating TTL serial data to SPI and vice versa.

PIC micro-controllers are cheap at around $1.00 ea for an 18F06Q41 that can run at 64MHz with an instruction time of 62.5 nanseconds. It also has 2 Hardware SPI peripherals and 3 Hardware USARTs ... as well as Peripheral Pin Select and a host of other features. One could incorporate something like this with a NRF24L01+, CC1101 or Si4463/38, etc front end module with a component cost of about $10 or maybe less.

However the major "cost" is the time required in developing and testing the code required to make it all work, specifically the code related to whatever RF IC is selected. This is time that I am not really willing to invest ... where there is no return on the investment except for, a few "atta boys", and likely many hours of free "customer support".

I did a wireless programming project for another PIC based platform a while back. First I had to write a bootloader in PIC ASM for the target chip to allow for UART/TTL serial programming, then develop the code for the PIC microcontroller that controls the wireless transceiver front-end module. It is quite fast as it operates at 115200 baud and transmits programming data in 64 byte blocks with a checksum instead of the byte-by-byte validation method required with a Picaxe. This took quite a bit of time as I am not a programmer by trade and had to learn the RF stuff along the way.

We will soon see what the HM-19 does, but I am not expecting much in regards to programming speed.

Goey
 

inglewoodpete

Senior Member
... where there is no return on the investment except for, a few "atta boys", and likely many hours of free "customer support".
Well Goey, A BIG "attaboy" from me. While I may (or may not) use wireless programming in the future, your efforts and willingness to share your process and its results is much appreciated. Having developed and documented a few PICAXE (and non-PICAXE) projects over the past few years, I fully understand the time and attention to detail that is required. Documenting a project for posting on-line can take considerably more time than many would expect.
Peter
 

hippy

Technical Support
Staff member
I did a wireless programming project for another PIC based platform a while back .... It is quite fast as it operates at 115200 baud and transmits programming data in 64 byte blocks with a checksum instead of the byte-by-byte validation method required with a Picaxe.
Unfortunately the PICAXE is something of a 'victim of its own success'. The PICAXE was developed long before USB was prevalent, needed to be RS232, had to be relatively low speed, 4800 baud, to work, and had to be reliable. The byte-by-byte transfer is robust and and works well for serial cable transfers, RS232 or USB.

Unfortunately that's not great for wireless programming where additional transmission delays become a factor, and we are stuck with having to use the original protocol to be compatible with all the PICAXE chips which have been sold. A lot of schools and others are still using early PICAXE devices and it's not easy to support multiple protocols without excessively complicating things, both technically and practically.
 
Top