Help with URF and ERF please!

Memran · Oct 30, 2012

Hi all,

I got my shiny new URF and ERF pair today and have had some intermittent success, but now I cannot get them to talk.

The first few tries resulted in random transmission failures when programming an 08M2+, but some of the time it worked.
Now I just can't get it to work.

I tried lots of things like USB extension cables, different positions of the URF in the room, changing power supply etc

Just using putty to send data fails, with the DTR LED not flashing as it used to.

The heartbeat LEDs on URF and ERF both blink continuously.

I am at a loss, please help!

Big image: https://dl.dropbox.com/u/60412649/2012-10-30%2023.26.34.jpg

Technical · Oct 31, 2012

If the DTR LED does not flash then there is no serial communication at all.
Not sure how putty resets the COM port?, try with the Serial Terminal within PE instead. Remember you must reset (close then reopen) the COM port every time you make a hardware change.
Have you tried programming the 08M2 with a direct cable link? We would also add a 10k resistor between leg 2 and 0V to provide a strong pull down on RXD when the ERF resets.
And we assume the top power rails and bottom rails are joined on your breadboard!

Memran · Oct 31, 2012

Thank you for your reply

Each time I try with putty, I have started a new session.

I did try with the Serial Terminal too last night. Any data sent from that did not cause the DTR LED to flash.
Just about the only thing that does make it flash is attempting to program the 08M2. The LED blinks 3 times at about 1 second intervals, and then the PE says it cannot find hardware of the pic.

Programming the 08M2 does work as expected with the USB cable.

Yes, the top and bottom rails are joined on the breadboard.

I will try adding the pull down resistor to RX when I get home from work today.

Something else I tried was to use the two programming apps which can change the frequency setting. I tried each of the frequencies. The URF app reported that it was programmed for PICAXE use, and the ERF app runs fine on the 08M2 and debug output says that the ERF was successfully setup. This seems to confirm that TX and RX are working in the ERF itself for changing settings.

jinx · Oct 31, 2012

The guys n girls here are good at solving most issuses but it would help if you post your test code ," A rule of thumb when bread boarding is too have positive and negative on opposite rails if that makes sense.
jinx

where are your caps 100uf/nf.

Memran · Oct 31, 2012

Thanks jinx

However, I don't think posting code will help with this problem, as it is pre-code

The problem is getting the two modules to talk at all, to enable programming of my pics.

I'll take on board your comment regarding the +ve and -ve rails though, because it should make the production of "magic smoke" less likely!!

hippy · Oct 31, 2012

Memran said:
The problem is getting the two modules to talk at all

Remove the PICAXE from the equation; strip the breadboard circuit down to just ERF module and power, connect the ERF "TX" and "RX" pins together. That way, anything sent via Terminal or Putty should be echoed back to the PC.

When using the URF and ERF, try to ensure a metre distance between the two.

Memran · Oct 31, 2012

Thank you hippy, I will try this when I get home from work.

Memran · Oct 31, 2012

I have tried what you suggested hippy, but still no data is being passed to ERF

I also tried Technical's suggestion of the 10k pull down on RX, but that also did not work.

Maybe they are faulty?

Memran · Oct 31, 2012

I tried using the two apps to program back to defaults:

ERF:

URF:

Memran · Oct 31, 2012

Test without pic:

I cannot get a response from PE Terminal or Putty, or programming.

Tried all baud options in terminal.

Memran · Nov 1, 2012

I just managed to get the DTR LED to flash by writing a small java program to send data at a lot of different baud rates, with the intention of finding one that works, but found that the LED flashes at all baud rates I tried.

Code:

package com.rr.serial;

import jssc.SerialPort;
import jssc.SerialPortException;
import jssc.SerialPortList;

public class ScanPorts {

	public static void main(String[] args) {

//	 String[] portNames = SerialPortList.getPortNames();
//        for(int i = 0; i < portNames.length; i++){
//            System.out.println(portNames[i]);
//        }
		
		int[] bauds = new int[]{
			300,600,1200,2400,4800,9600,19200,38400,57600,76800
		};
		
		for(int baud : bauds) {
			System.out.println("Trying "+baud);
			SerialPort serialPort = new SerialPort("COM13");
	        try {
	            serialPort.openPort();//Open serial port
	            serialPort.setParams(baud, 
	                                 SerialPort.DATABITS_8,
	                                 SerialPort.STOPBITS_1,
	                                 SerialPort.PARITY_NONE);//Set params.
	            serialPort.writeBytes("This is a test string.".getBytes());//Write data to port
	            serialPort.closePort();//Close serial port
	        }
	        catch (SerialPortException ex) {
	            System.out.println(ex);
	        }
		}

	}

}

However I still cannot get putty, PE terminal, or anything else to make the DTR LED flash.

What could be different with the way my java code sends data?

In addition, I cannot get any data into my pic with serin C.3,N4800_4,b0 or any other baud I have tried.

Technical · Nov 1, 2012

You are jumping around a lot and so that makes it hard to follow your tests. But if it works in java there is no reason why it shouldn't work anywhere else.
The URF does not care about baud rates, they are irrelevant in an 'over air' system. Only the ERF has a baud rate setting, and if RX is shorted to TX again that doesn't matter either, as both pins will be using the same baud rate.

1) rebuild the circuit from scratch on a different part of the breadboard. Make all power connections to the same rail, not some above and some below.
2) connect RX to TX on the ERF, do not connect it to a PICAXE chip
3) remove the URF from the computer. Put it back in a different socket, so that it is allocated a completely different COM port number and the driver is re-installed from scratch.
4) if possible, connect the URF to a computer by a USB extension lead.
5) Make sure ERF and URF are at least 2m apart
6) Do not use putty, use PE serial terminal on the correct COM port. Type some text, click send, and see if it is echoed.

Memran · Nov 1, 2012

Thank you for your continued patience!

Apologies for trying lots of different things at once.

I've done precisely what you suggested here, except that even after removing and re-installing the URF driver, it is always on COM13, despite which USB port it is plugged into.

Here is my new circuit:

There is nothing else on the breadboard.

Heartbeat LED is blinking on both ERF and URF, and the URF is 2m away on extension.

Now for PE terminal, to make sure I am not doing something dumb, here are my steps:

Options, Serial Port, COM13, OK
PICAXE menu, Terminal...
Type into Output Buffer, Send

DTR LED does not flash, and nothing appears in the Input Buffer.

Memran · Nov 1, 2012

In addition, I also tried the URF in a different computer, but got same result - nothing

I managed to change from COM13 to COM14, and get same result again.

Arg! I'm doing it again: trying lots of things! I'll stop now!

Memran · Nov 2, 2012

I've done some more tests with my java app, and I conclude that it is in fact *not* getting data to the ERF. The DTR LED flashes only when the port is opened, and not on subsequent writes.

I'm pretty sure at this stage that the URF or ERF is faulty.

Memran · Nov 2, 2012

Confirmed with PE Terminal! I was just watching the LED at the wrong time!
The LED blink when Terminal is started, but not on subsequent sends.

Memran · Nov 3, 2012

Any more ideas?
Or is it time to give up?

Memran · Nov 4, 2012

Shameless bump, due to no solution

Technical · Nov 4, 2012

In post 1 you stated you did have some reliable transmission (successful remote programming) to start with, with just a lost packet every so often (as could be expected if the units were too close together, wobbly wire etc. etc).

So something has gone wrong somewhere down the line, and if not physically damaged (e.g. by a wiring mistake) it could be just that you have corrupted settings in the units whilst reprogramming. If you want to send them back to us we can certainly check for you.

Memran · Nov 4, 2012

Thank you, I would really appreciate it!

I will post them first thing tomorrow morning.

Help with URF and ERF please!

Member

Technical Support

Member

Senior Member

Member

Ex-Staff (retired)

Member

Member

Member

Member

Member

Technical Support

Member

Member

Member

Member

Member

Member

Technical Support

Member