RS232 Serial Converter (CE04442) Logic Levels

[Robert93820]

Hi Michael
Thanks for that. Explains it all. Had me tricked a bit. Over the years I have handled many thousands of Sub D connectors and when the very few times (probably could count on one hand) I have needed this configuration I have always done as described above with a threaded back shell.
Cheers Bob

@Michael99645

USB to RS232 converter, so should have the “same” interface as you would have expected on the back of a PC.

In that case this would be DTE (terminal equipment) as in Computer. It is understandable that another computer or “Terminal” would require a cross over cable to connect the two.
It is therefor feasible I suppose that the black box bit could be regarded as another computer or terminal device even though it looks to be DCE “Communication Equipment” as it is the radio carrier (I think as this is where I get confused) as is a Modem a Communication Equipment so no cross over required when connecting a PC to it.

I think I should let others worry about it. My old brain is slowing up a bit.

[UA19]

Hi Michael,

Thought I’d give a quick update. I’ve been able to connect and configure my DTUs using a Waveshare USB to RS232/RS485 connector (below). I’ve done this via both interfaces (RS232 and RS485), albeit I had to create a pseudo Null Modem cable for RS232 (3 pins only - GND/Tx/Rx).

I’ve managed to achieve end to end communication between two units with largely out of the box configurations using the Waveshare USB to RS485 on the laptop and RS232 with the Pico 2), although the data is garbled - about to start debugging this when time permits today hopefully.

Configuration as follows.

Unit 1: +AllP=7,0,1,22,0,0,1,18,18,0,0,2,9600,”8N1”,0

Unit 2: +AllP=7,0,1,22,0,0,1,18,18,0,0,3,9600,”8N1”,0

The Pico 2 is connected directly to the DTU via the CE04442 RS232 Serial to TTL UART converter. I’m running a test program that iterates through the digits 0-9, sending a single digit every 10 seconds, pausing then for 20 seconds and starting again. I’m seeing the Tx led on the unit light up every 10 seconds and the other DTU’s Rx led light up almost simultaneously (as expected).

The second DTU is connected to my laptop via the Waveshare USB converter. I’m running the Arduino serial port monitor to view the data received. As mentioned, the data’s garbled, but I’ve got a couple of thoughts on the issue.

[Michael99645]

If you can get a HEX output of the received data it may help.
Normally the defaults should be fine.
I wonder if the encryption keys are different (you would expect them to be the same defaults.
I cant test this until I get home, but you should be able to set the AES key via

AT+KEY=0\r\n                                           Set the key, the value range is 0~65535, 0: prohibit encryption, 1~65535: encrypt the transmission key value

So for debug maybe try AT+KEY=0 first (no encryption)

[Robert93820]

Hi UA19

@UA19

As mentioned, the data’s garbled, but I’ve got a couple of thoughts on the issue.

Refer your top pic.
The connections for RS232 look IK
BUT the selector on that Waveshare device appear to be RS485 selected.
NO 120Ω terminating resistor which is correct.
Could be the reason for garbled data as RS485 and RS232 have no similarity whatsoever.

If I am wrong about switch positions and the reverse is true then the RS232 will have a 120Ω resistor between TX and RX which could cause all sorts of behaviour.
Cheers Bob

[Michael99645]

A deeper look at the config (reformeted to align the values)

Unit 1: +AllP=
	UNIT 1	UNIT 2
SF	7	7	SF7
BW	0	0	125Khz
CR	1	1 	Coding Rate 4/5
PWR	22	22
NETID	0	0
LBT	0	0	Disabled
Mode	1	1	Stream Mode
TXCH	18	18
RXCH	18	18
RSSI	0	0	Dont Append RSSI Info
ADDR	0	0	
Port	2	3	Unit 1 - RS485, Unit 2 - RS232
Baud	9600	9600
        ”8N1”	”8N1”
AESKey	0	0	Key 0

Main thing that jumped out was Unit 1 looks to be set for RS485 I/O and Unit 2 Seems to be set for RS232. While you can only select one, there may be some path to both outputs.

So linked to Bobs post, you may have have a mismatch.

[UA19]

Robert,

Apologies, the picture was indicative only.

It was set correctly when I was testing.

Good pickup though!

[UA19]

Apologies, as per reply to Robert, the picture was indicative only.

[Robert93820]

Oh Great. That means we can’y trust much else either.
I just love people who post information knowing it to be incorrect.
Sorry but in my world no excuses for that.
Cheers Bob
But i will accept that apology as long as the practice is not repeated.
Post as accurately as you can please and if you know it is not correct don’t post at all

[UA19]

Robert,

The picture you viewed in the post above is the face of the Waveshare USB device which has that graphic emblazoned on it. The switches for setting the interface type and resistor are on the side of the device and not visible. So in hindsight, I’m not sure why I’m apologising. I set these appropriately depending on the test scenario (i.e. interface RS232 or RS485).

[Michael99645]

@UA19

Pico 2

I had a bit of a play when I got home. If i set the wrong prot type, e.g. RS485 when it should have been RS232, nothing would come out the RS232, lights flash ok.
Next quick test was correct ports, but wrong baud on one device. This resulted in the lights flashing on both units, but the RX data was wrong (as expected).

So double check your com port settings on the PC and Pico.

Edit:
from my testing and play, these lora units can be seen as store and forward.
By that, I mean…
the comport and baud rates can be different at each end. e.g. Can have a 115200 RS485 on one end and a 9600 RS232 on the other.

i.e.
115200 RS586 → Data into module. Now its just the raw data post coms.
Lora Module sends data to remote unit - data packet over the air.
Remote Lora Module then clocks out as per its setup.
The main thing to keep an eye on is to not over run the input/output buffers. To help with that you may just make all the data rates the same.

[UA19]

Hi Michael,

Yes - I’ve checked the COM Port settings and they’re aligned.

Got sidetracked with other activities today, so I’m only now in the process of capturing a hex dump. I’ll do it twice to see if it’s generating the same data each time.

Thanks

Edit:

Read your updated post. Given that I’m only pushing data from the Pico (one character every 10 seconds) and capturing it via a Putty serial session at the laptop end, I’m pretty confident that I shouldn’t be over-running the buffer. As mentioned previously I’m seeing the Tx led (sending unit) and Rx led (receiving unit) flash in sequence, so it would appear there is some over the air transmission happening.

I’ve also now captured two Putty raw log files. Process - I powered down both DTUs, then powered up the receiving unit and set up the Putty session. Then I powered up the sending DTU and waited till it sent all 10 characters (‘0’-‘9’) and then shut it down, followed by a shut down of the receiving DTU. I followed this process again, with the expectation that it should have generated two equivalent files - but alas they’re different.

So now I’m going back to basics and rechecking everything at the sending end first and then the receiving end. I’ll post my findings after a thorough revisit tonight.

Thanks

[Robert93820]

Hi UA19

@UA19

he picture you viewed in the post above is the face of the Waveshare USB device which has that graphic emblazoned on it. The switches for setting the interface type and resistor are on the side of the device and not visible.

OK, as I don’t have one of these devices I was not aware of that. I am probably never going to have one of these things as it has Waveshare on it but that is another story. The pic looks like the actual switch. Pretty misleading. I think it might have fooled Michael as well as he didn’t comment.

Anyway all sorted and explained. So I will leave you to it as I know nothing about the rest of it. There was a longish previous thread about this set up which Michael linked at post 14 above.
Might be worth a read. I am not sure what the final outcome was now.
Cheers Bob

[UA19]

Michael,

Problem solved - end to end communications now working.

The problem was that I have my Pico 2 mounted in a Core Electronics PiicoDev LiPo Expansion Board, and I have OLED display and RTC modules attached to the Qwiic I2C connector at the bottom of the expansion board. The default I2C SDA/SCL pins are GPIO pins 4 & 5, but the expansion board uses GPIO pins 8 & 9 for the Qwiic connector.

I didn’t look closely enough and unfortunately was attempting to use pins 8 & 9 for UART 1, conflicting with the modules on the I2C bus (Qwiic connector). Swapping to GPIO pins 4 & 5 for UART 1 fixed the problem (mea culpa). I can now move on to trialing packet mode.

Thanks for all your support

[Michael99645]

Great to hear its all working.

I tend to use the esp32 for most things and the idf, then select what pins do what. Really handy if you need to re assign due to space layout challenges or post pcb mistakes for v1.

[UA19]

Hi again Michael,

Just tidying up a couple of things.

I’ve been testing with primarily default parameters on the DTU, but note I’ll need to change its channel number setting for the LoRa AU915 plan (out of the box default = 18 ~ 868MHz, with 850MHz - 930MHz range of unit). I’ve calculated that would mean channel 50 for 915MHz. I’m looking to set it a channel 51. I don’t have a spectrum analyser to check local utilisation, although I don’t expect that to be a problem when deployed in far western Queensland (noting you had problems in Vic with electricity metering).

Am I correct in my calculations here.

[Michael99645]

I did map it a while back, but lets just reset and see.
Im using a hackrf1 and sdrsharp for this test.
Channel 18, as you expected seems to be 868

So some math…
have have channels 0-80 that covers 850~930MHz
Range = 930-850 = 80
so looks like 1 Mhz per Channel.
That would put channel 65 at 915 Mhz (850 + 65 = 915)
Lets check what the SDR sees.
(while not centered on the screen, the label shows 915 at the red virtual marker)

So that looks right…
That should then mean the following table should be correct. (freq. in Mhz)

edit:
note: When I change the TX it did not change the transmit frequency, which I would have expected, but did change the Transmit Frequency when i change the RX channel. So this seems backwards me; seems like TX is what the other unit needs to send on, and RX is what the other unit should listen on…
To keep it simple, just setup both TX/RX to the same channel

[Robert93820]

Hi Michael
Re your edit of last post.

My personal opinion is if it has anything to do with Waveshare anything could and probably will happen. Except what you think logically that is.
Cheers Bob

[UA19]

Agreed - keep them on the same channel (probably use 67)

Once again,

Thanks for your support