RFA020/021 pair problems

A

Adrian Hudson

Member
SOLVED: URF was faulty

Hi All,

I wonder if someone could help me before I tear my hair out.

I bought a URF/ERF pair to program a PICAXE 28X2 module over the air and also send low volumes of data to it.

"Lets not run before we can walk", I thought. So I put the ERF on a breadboard, connected it to 5V, pulled CTS low to 0V. connected up an LED to DTR and to 0V via a 1K resistor and finally connected RX to TX. Seeemples as the meerkats say.

I plugged the URF into a Win 8 laptop. It didn't pop up with an "Installing hardware" notice but installed a driver that must have come with windows. I downloaded the driver from the PICAXE website anyway and attempted to install it. Win 8 said "Already have the latest driver installed" - so I forced an update using hardware manager and "I have a disk" etc.

Okay, I thought... good to go! I powered on the ERF first (heartbeat flashes), plugged the URF in (heartbeat flashes), fired up the programming editor and the terminal window. Set it to 9600 (as this is the ERF default) and typed some characters and Send expecting thm to be send on a round trip to the ERF and looped back (as RX is connected to TX).

Nothing, zilch, nada. The LED on DTR does nothing (it IS round the right way!!) either.

Tried 4800, 2400 etc etc. Pored over the half dozen wires on the breadboard... hard to make a mistake with that minimal a circuit.

I decided to see if the Programming Editor's "Options/Serial Port/Show port help tools/Test Port button" would have any effect (with the loopback at the ERF disconnected). Interestingly enough, with the "LED" (the button in Test Port) off, I get 0 volts at TX. With the LED on, after a 5 second pause(!), 3.36 volts... so the IS some comms going on.

I have noticed that as I change from baud rate to baud rate in PE Terminal the LED on DTR flashes but that is it, no flashing when I type characters in terminal and send them.

Technical Support @ Picaxe suggested I try the above again when I suggested the ERF might be faulty - which I did to no avail.

I decided the ERF board was faulty and bought another. It acts in exactly the same way.

My son, a PhD student, who is working on a quantum computing project happens to be home... He has double checked me and is stumped too (I just thought I would throw that one in!).

Oh, one last thing, I deinstalled the URF device on the Win 8 laptop and reinserted the URF, it loaded the preinstalled driver and I tried that. No difference. My son suggested the issue might be RF interference from the laptop so I tried the URF in a desktop on the end of a USB flylead. No difference.

So, before I buy another URF module... HELP, PLEASE!!!
 
Last edited:
A

alband

Senior Member
I'd like to help, but I'm no expert. Only things I can think of:

  • Try it on a non win 8 machine if possible?
  • You say you ordered another ERF module which behaved the same, mostly likely they're both fine. Could you see if you could get the ERF boards talking to each other, no computer involved, so you'd need two PICAXE's. Program one PICAXE to serout something, program the other to flash an LED when it get's a serin. Once that works, get the receiving PICAXE to sertxd what it recieves from it's ERF board. If what you get through the terminal is what you programmed the sending PICAXE to send, you know both ERF boards are good. You could also do this test with one PICAXE and the loopback connected.
  • Another thought is that the results from the Test Port Button thing seem dubious, especially the 5s pause. I doubt that test is meant to work at all with the URF/ERF modules, it'll depend how the driver was written.
  • When you were doing the first test with the loopback connected, what stuff did you send via the terminal? I've had trouble in the past with terminal message not getting through due to the data not being a text string, or being a text string, and just getting no response. Seriously doubt it's that though.
  • Another thing to try might be programming a PICAXE to send something via sertxd though the ERF/URF and see if that is picked up in the terminal. To me, the fact that the DTR flahes when you change baud settings suggests it's working more than anything else.
Sorry I can't be more help, but at least you might be able to cross some things of the "could be at fault" list?
 
A

Adrian Hudson

Member
@alband,

Thank you very much for your suggestions, I am much obliged. You obviously read my plea for help carefully and thought about my problem.

So far I have tried a Win 7 machine. Interestingly it too seemed to have a driver out of the Windows box for the URF but I replaced it with the one downloaded from RevEd. Still no luck.

I will try your other suggestions and post back my results! Thanks again for your hep. This seems so basic and aught to be dead easy but is proving maddeningly difficult!
 
hippy

hippy

Ex-Staff (retired)
Adrian Hudson said:
So far I have tried a Win 7 machine. Interestingly it too seemed to have a driver out of the Windows box for the URF but I replaced it with the one downloaded from RevEd. Still no luck.
Click to expand...
It seems surprising that Windows would know of a driver for the RFA021 / URF but it is possible. Rather than guess it would be worth looking in Device Manager to see what Windows says is connected to the COM port being used. Given the ERF does respond to the 'LED test' that would suggest the right driver is being used.

It is very odd that the ERF appears to respond correctly to the 'LED test', but you don't have full comms working and it is exactly the same with two ERF devices.
 
A

Adrian Hudson

Member
@hippy, thanks for the reply. I should have said, I looked in Device Mangler in Win 8 and its out of the box driver calls the URF "TI CC1111 Low-Power RF to USB CDC Serial Port". In fact on my desktop machine Windows 8 refuses point blank to install Rev Ed's driver as it isn't signed and there is no "Just do it anyway" button.

Actually, I have just told a Win 7 machine that had RevEd's driver installed to update its driver to the most recent. It looked on the web and overwrote the driver with one that has the identical name to the Windows 8 default driver. I tried the LED test again and it still works, i.e. with the LED button On, I get 3.34 volts on the TX pin of the ERF. Its really weird, sometimes there is no delay, sometimes there is up to 5 seconds before TX goes high.

Anyway, I am using Windows 7 from now on to avoid uncertainty.

I have tried pulling the looped TX and RX low and high with a 10K resistor before trying the loop text. No idea if that was a worthwhile thing to do.

If I try programming the Picaxe over the URF/ERF (which doesn't work, it just gives up) I can see the three attempts the programmer has by the DTR LED flashing.

I have tried using sertxd to repeatedly send a message back to the serial terminal but I get nothing and not DTR activity.

Having said that, I have noticed that the DTR LED flickers almost imperceptibly almost all the time, even with the URF disconnected from the PC. Next test is to power it from a battery so I can wander down the road in case there is RF interference in my house.
 
A

Adrian Hudson

Member
Forget the flickering thing. That was new and I think it might have been a power supply issue.

Here is a photo of the breadboard. As you can see, dead simple.

130406-212036.jpg

On power on, the heartbeat led flashes quickly three times and then slowly once a second. On plugging the URF into the PC I can see the DTR LED flicker - I assume as the units talk and the baud rate is set. If I open terminal DTR flickers briefly each time I choose a different baud rate. As you can see, TX and RX are linked. When I enter data into the terminal window and click send there is no activity at all. The only way I can get DTR to flicker is to change baud rate in Terminal or unplug/plug the URF.

Do these things actually work? Has anyone had them working??
 
Technical

Technical

Technical Support
Staff member
The URF doesn't actually have a USB driver, just an INF file that points Windows to use the default CDC driver. So the INF file used doesn't really matter and it doesn't matter either what the COM port ends up being called.

The DTR LED shouldn't flicker all the time. What happens when you tie CTS high - does the hearbeat stop? If you hadn't said otherwise we would have guessed that CTS was floating from what is actually described.

Can you communicate OK with the URF via the configuration wizard at www.picaxe.com/downloads/urf.zip

You don't seem to be doing anything wrong, they generally work first time for most people so there must be an issue somewhere. On Monday we'll test one from the shelf stock on a Windows 8 machine.
 
Last edited:
A

Adrian Hudson

Member
Hi Technical, thanks for the reply. See my post 1 min before yours. Yes, I can communicate with the URF with the wizard, no CTS isn't floating and the flickering was a red-herring and might have been a power supply issue (I have changed power supplies - no improvement other than the flickering.) Heartbeat does stop if I tie CTS high, yes.
 
A

Adrian Hudson

Member
Okay. I can get two ERF's talking. Worked first time. Still no luck getting URF to ERF comms going. So, its likely to be the PC/URF end of things. I made up one breadboard with a picaxe and ERF sending some characters every second. I made ip another board the same with the picaxe programmed to send whatever it receives to sertxd. The characters the first picaxe sent to the second were echod to the serial terminal perfectly.

I reasoned that if I switched off the sending breadboard and plugged in the URF, determined the com port it was using and DOS COPYd a small text file (a few byes) to the com port, the receiving picaxe should receive the data and echo it back to the serial terminal. Nope. Nothing. Nada.

Is my URF duff? I wonder.
 
A

alband

Senior Member
Is this still the first and only URF board? Sounds like the culpret to me. Possibly Technical or someone else can suggest a test for the URF?
 
A

Adrian Hudson

Member
Yes, this is my only URF. I have struggled all afternoon and am convinced something is wrong (with it).

I will have to use an ERF board at both ends for my project, but I really wanted the over the air programming :-( I can make the ERF boards work fine. I have to program them to use a lower baud rate if I want to use the "SERIN [timeout], pin,baudmode,(qualifier...),{#}variable,{#}variable" construct as the 28X2 doesn't seem to be fast enough to process that command at 9600 but thats not a problem. My project would be quite happy at damp string speeds.

Does anyone know the right pins in a 9 pin serial D connector to connect to an ERF to interface it directly to a PC?
 
Technical

Technical

Technical Support
Staff member
We've taken a brand new pair of ERF/URF from stock
1) Recognised by default on Windows 8, no driver requested and COM port allocated immediately.
2) Loopback test worked first time, no problems found.
So we can only assume in this case it is indeed a faulty URF - please send it back and we'll test it for you.
 
A

Adrian Hudson

Member
SOLVED: The URF was faulty. Thank you Technical for replacing it. I plugged it in, no drivers needed, it worked immediately. Programming my heating controls in my airing cupboard from my study now!
 
You must log in or register to reply here.
Top