connecting an erf module via the download socket?

[geoff07]

Has anyone done the work to enable an erf module to connect into a Picaxe board via the download socket? It didn't work when I tried it so I expect the 22k resistor is a problem, needing some sort of signal conditioning.

It would be so much more useful to reprogram fixed installations in the house if I didn't have to hardwire an erf (or at least a new header) into them.

I will try to do it myself if noone else has, but 'on the shoulders of giants' ..

 

[hippy]

I don't think I ever tried it because the ERF needs a power supply and you can't get that through the download jack.

You could wire up the ERF as it is recommended to be on breadboard, direct to PICAXE pins, check it works and then replace the link to Serial In with a 22K ( and 10K pull-down on the ERF side ) and see if it still works. If not then the 22K would seem to be a problem, if it works then perhaps it's a wiring issue on the ERF jack plug side.

Note that you probably cannot do this with a standard board as the 'unused' 22K and 10K resistors for the download jack will act as a potential divider with the 22K to the ERF.

 

[geoff07]

Yes I realise it needs a batt. I will have to experiment some more. As a product, it would be much more useful, for me at least, if it was a simple plug replacement, albeit with a batt. There is something neat (and convenient) about sitting in the house reprogramming the central heating controller (which is in the garage) by radio. The alternative, which I can do for the web pages on the net server, but not for the download, is using the wifi. A (pluggable) wifi-based download product would be really neat.

 

[hippy]

Just tested an ERF with 20X2 on an AXE091 board using a 10K/22K download interface for the ERF paralleled to the jack download circuit ( no cable plugged in ) and that worked even with that acting as a 22K/32K potential divider. Not an exhaustive test but it should work with what you have.

I would double check your ERF to jack plug wiring.

 

[geoff07]

pluggable radio download gubbins

Thanks hippy!

Well, on the basis of hippy's test I assumed I must have got the rx/tx links crossed, and it would in fact work. I'm sure I agonised over the rx/tx polarity at the time and thought I had tried both but obviously not. So I made up a little board using an 08 proto-board (I keep a supply for just such little projects). This uses a double-ended stereo lead to connect to the project board. The ERF plugs into a header so I can use it for other things (they aren't cheap).

Once I had remembered to a) install the SRF driver, and b) use a USB extension on the laptop end (so the SRF wasn't confused by computer hash), it worked.

I did get verification errors at medium range, so am curious - does the link error-correct or just error-check? Download speed is a tad slower than using the cable, but I daren't try to increase it until the range is sorted, so the next thing is to try the other frequencies to see what difference they make to range. I have other gear (radiator thermostats) on the 868 band so they may be the problem.

Doing this makes the whole thing much more useful for downloads. The pic shows what I did.

 

[hippy]

I'm sure I agonised over the rx/tx polarity at the time and thought I had tried both but obviously not.

It's easy enough to do even with a full circuit diagram. I find it best to start with "ERF TX goes to Serial In" then write down all the pin numbers, connections and wire colours for that. Do the same for "RX from Serial Out". Then work back from the ERF towards the PICAXE. A final continuity check to confirm it's how it should be.

I did get verification errors at medium range, so am curious - does the link error-correct or just error-check?

I believe it's only error-checking. If the check fails the packet simply isn't delivered to the PICAXE (ERF) or PC (URF/SRF).

Download speed is a tad slower than using the cable,

There's a slight delay while the ERF/URF/SRF waits to see if there's any more data to be sent before sending the data so this can delay the transmissions slightly but shouldn't be too bad overall. During comms the PC program will usually be 'swapped out' and in most cases, hard wired or wireless, the data should come back and the downloader 'swapped back in' at the same rate.

the next thing is to try the other frequencies to see what difference they make to range.

The chip aerial is I recall best tuned for 868.3MHz but it's worth having a play.

 

[geoff07]

There is a slight anomaly when trying to use the serial terminal over erf/srf.

Despite having '#terminal 9600' in the code, the terminal window had to be set to 19200 for the output to be readable. I had been using PE6 so I tried it again with PE5 and found that the same is true for both versions.

I had understood from the words that port speed setting was automatic, but perhaps not with this gear.

 

[hippy]

Whatever a URF receives it will display no matter what the Terminal baud rate is as there is no baud rate per se for the URF being a USB connection.

Altering the baud rate of the URF should however alter the baud rate of the ERF. A baud rate change becomes a message to the ERF to change its baud rate.

This means that any gibberish seen would solely arise from a mismatch of the ERF baud rate and the PICAXE. So if Terminal is set to 19200 baud, the ERF will have followed suit and be at 19200 baud, and the PICAXE would have to be communicating at 19200 baud for the output to not be gibberish.

If the PICAXE is not using 19200 that would be odd and I don't recall having observed that problem myself. It's feasible the PICAXE is using 9600, so is the ERF, and that somehow the change to 19200 never passed over to the ERF but not sure why that would be or how it came about.