The RS232 signals coming out of the arduino (via the adapter) are fine.
IDK which picture you are talking about, PXL_20240221_035014674 is the TX side and TX goes into RX
The one thing no-one has asked me is what my ardino code looks like. I think this is the problem as I am using the LoRa units as if they were transparent serial links. Instead, I believe I need to use a library to send correctly structured and formatted packets so will look into this next.
Hi Taylor
That is the pic I am looking at which you now say has a TTL to RS232 converter installed.
I believe the connections to the converter should be:-
Arduino TX to Converter RX (board pin). I think the Converter is considered a DTE device so cross connection of TX and RX is required. Other pins as indicated. Then the Arduino and converter would be considered as a DTE device and the converter should repeat anything input to it at the TX pin (DE9 pin 3)
Connection from Converter (DTE) to LoRa device
Converter DE9 pin 3 to LoRa (DCE) DE9 pin 3 (TX)
Data output at receiving LoRa device from DE9 pin 2 (RX).
This will be RS232. If you want TTL you use another converter in reverse.
Connection from RX LoRa (DCE) DE9 pin 2 to converter RX DE9 ( pin 2)
Output from converter (DTE) Board pin “TX” to TTL “RX” pin on receiving MCU
If you connect from converter to converter (Both DTE) you should cross connect TX and RX. That is DE9 pins 2 to 3.
I stress this is the way I THINK the connections should be made. It depends on whether the LoRa device is considered DTE or DCE. I would think DCE (Data Communication or Carrier Equipment) as the function is to transport data from point A to point B. DTE indicates Data Terminal Equipment such as Computer, Arduino, RPi etc.
Cheers Bob
1 Like
Hey Taylor,
Would you be able to post your code so we can make sure that it doesn’t contain any obvious faults? Using a dedicated library is definitely something that’s recommended if your still new to LoRa networking with Arduinos.
Have you had any luck with your connection setup?
Thanks,
Sam
the way I read the wiki is there are 3 modes, where the default is streaming. In this mode send send that data into the unit and it sends it. The RX unit then gets that and dumps it out the interface.
then packet mode you would need to add device ID to the start of the data you want to send; but the default is streaming.
I would start with trying to get your PC connected to each unit and get the AT commands working (i.e. +++ to enter AT mode)
If this does not work (default baud 9600) then that needs to fixed first.
Once both units can talk to the PC in AT mode, you can ensure both units are in the same state/modes. e.g. encryption key, transfer mode and so on.
Only after both units are working in AT mode and the settings are correct, would I suggest to move onto the micro controller tests and code.
i.e. you should be able get them to talk to each other with nothing more then the RS232 connection to the PC and putty.
1 Like
Ok, great, that’s all I want to do so Stream mode sounds like the way to go.
I’ve checked the output from the Arduino and its attached converter and that signal looks good.
I’ve tried using the AT commands again and now am finally having success. The devices are definitely defaulting to 115200 baud, contravening what the manual suggests as the default baud rate. So learning that’s a start.
1 Like
Hi Taylor
I haven’t got a set of these LoRa units or tried to find a handbook. BUT in STREAMING mode would not the LoRa accept what is given to it (within limits) and simply repeat at the other end. Or in other words go into an “I don’t care” situation and depend on the attached equipment to understand what the other end is saying. As you say, I think this is the mode for you. You don’t want to start adding complexities in the middle. The LoRa devices should just be a carrier medium and be ignorant of any particular protocols. Just needs to know what system (RS232, RS422, RS485) is in use. I would imagine it would be very important to have both ends set the same.
Cheers Bob
Add on.
When you get the connections sorted would you please post the results here. I and probably many others would be interested to know whether my earlier assumptions re DTE and DCE and cross connection requirements are correct
1 Like
Bob, from what I read they are lora, and stress not loraWAN/
I did order a pair to have a play with (on back order)
So at the lora level, it is just a broadcast anyway (on set freq. etc)
So streaming mode is simple for broad cast.
AES can be turned on or off, but in my quick lock it was unclear how the keys works, rather you select in index to a key.
the next mode allows you to set a 3 byte (I think it was) ID, such that the transmitter would and the unit with AADDRR would drop the ID and send out the serial line. So this is just a simple step up from streaming.
But given its not loraWAN all the nice loraWAN stuff is not there as such, rather some propriety user managed thing.
I will be able to confirm more once my test units arrive and I have had a good play.
1 Like
Hi Michael.
I was not even considering LoRaWAN. Just trying to help sort out the RS232 confusion. And it CAN be confusing. It is the use (or misuse) of the TX and RX terms. Are they WRT the device you have in your hand (whatever that may be) or to the direction of signal.
While still working (as a contractor) one large project had a massive problem because of this. Consisting of 2 main sites and several small ones the 2 mains each had more than 600 audio circuits out of the site. Our project involved the audio or voice switching to lots of radio circuits and 39 x 16 channel intercoms. The problem was there were several process here and the different engineers with their different responsibilities tended to use the TX and RX terms WRT their own board design. Resulted in utter confusion.
My task was to look after the implementation and design of the installation which included all the detailed wiring documentation, cable design and manufacture, cabinet rack layouts (in consultation with engineers and customer) and generally put the whole thing together. Followed by actual on site installation as a team leader and preliminary commissioning assistance of the whole thing.
As can be imagined this TX/RX confusion had to be sorted at a very early stage as it was impossible to make any sense of it as far as acceptable documentation went. This involved a meeting with Project management, design engineers, our customer and myself.
Result, everything going away from the operator console (out of the building) termed TX and all incoming signals RX irrespective which direction they traverse individual boards or devices. Once decided upon this system worked very well. All turned out good.
This LoRa unit would seem to conform to this idea. The Data from the terminal Arduino or computer (DTE) Goes INTO the transmit pin (away from “operator” or work station) to be transmitted to the receiving equipment where it comes OUT of the RX pin.
The way I read it this adaptor is the funny bit. There are 2 main connections, one the DE9 connector and one the board edge connections. It seems that data FROM the Arduino or whatever goes into the RX point of the board connector even though it is going AWAY from “the operator” and comes out on the TX pin of the DE9 connector. This is from information gleaned from Taylor’s link which takes you to EBay
1 x 4 Header (Board edge side)
- GND = Ground – Connect to uC ground
- Tx = R1OUT on MAX3232 chip – Connect to uC RX line
- Rx = D1IN on MAX3232 chip – Connect to uC TX line.
- Vcc = 3.3 or 5V
This information does not seem available for the Core product or the cable sold by Core so it is anyone’s guess what actually goes on.
Cheers Bob
1 Like
My 2 units arrived and only had a quick play so far.
Initial findings/thoughts.
When the units first power up you have (about) 3 seconds to press the ‘key’ to enter firmware update mode. Outside of that you should not touch the key during those three seconds. When the unit is ready the tx and rx leds with do 1 quick blink… this is when you know its ready for normal use. Both of my units did that on first boot but for some reason (im yet to track it down) I managed to put both of my units into a mode where they were not in normal use mode (no led flash/blink) nor in update mode. As such I could not talk to the units on any interface (RS232, RS422 or RS485). I suspect I managed to set a flag that was trying to be in bootloader/update mode; but this is just a guess.
So, since I now had both units in the same “not really working” state, I did a firmware update (boot and hold key until both rx/tx leds go on then off) this put the unit into update mode. Where I could flash the latest firmware and both units returned to a working state.
Key point #1
Update mode is via RS425 and 9600, 8 data bits 1 stop bits.
Key point #2
“…RS485 half-duplex bus interfaces. (Starting from V1.2 firmware, RS485 is the default interface. The baud rate is 9600, and the mode is 8N1…”
If your on V1.2 or newer, the default user interface is RS485 and not RS232 as prior to that. While I don’t know when the shipping units would be on 1.2 or 1.3, both of my units were in default RS485.
So tip #1 if you are going to use these, I would highly recommend that you have an RS425 (to usb or as needed) adaptor handy; as you will need this to to any recovery or firmware updates.
Key Point #3
While i need to do a more detailed setup and test, the RS232 DB9 is 100% RS232 and not TTL. So an 232 driver of some sort will be needed be a connecting device. I will confirm the correct Pins once I have run some tests.
One nice thing, on both of my units, the Green Screew terminal unplugs. So you can leave your wires loomed and connected and remove the unit. This was also hand from my quick swap over tests.
Keen to hear about your further testing of these units Michael! I’m still not getting anything out of the RX unit despite the RXD LED flashing and having confirmed the serial interface specs via AT commands
Hi Michael
That would be correct. By the way as I mentioned it is DE9, NOT DB9.
I thought you were using on of these devices. You linked one and you have been posting as if you have been using it.
More importantly we have been replying as if you were using it.
Don’t tell us now that you have not and I for one have been wasting time on this researching operation and pin connections etc.
Cheers Bob
Hi @Michael99645,
Thanks for all that information from your findings.
Looking forward to hear about your findings when you do more testing with the modules as well.
Bob, point take on the DE9 not DB9
As to me having one, keep in mind I am not the OP. I have done a fair bit with lora and have read over the wiki in an attempt to help/assist the OP.
I did clearly state 21 days ago I was thinking of ordering some.
I don’t recall linking one, rather linking to the source or quoting from the a source.
Then 16 days ago I clearly said I ordered some.
So Im not to sure what your issue is with my posts and how the information provided by all response has not gone towards supporting the OP issue ? i.e. the OP was/still is having issues with talking end to end with 2 of these. After some responses he was able to get the AT command access, but still has not seen any data exit the RX units. i.e. I dont think any of this is time wasted.
Sorry If i have cause confusion somewhere.
1 Like
Hi Michael
Yes itches been confusing. And yes you did say 21 days ago that you were going to order “some”. and yes again you dod say 16 days ago that you had ordered “some” But you do not say exactly what the “some” is.
But 21 days ago you also posted
which led me to believe you had in your possession and were trying the TTL to RS232 adaptor.
Then a couple of days after, 19 days ago you posted
which sort of confirmed my assumption that you actually had and were using these adaptors.
So you will excuse me for thinking along these lines.
That is now starting to make sense. You are a 3rd party and you do not actually (up until now) have any of the devices under discussion. And all this time I have been thinking you have the set up in front of you so you can try out different suggestions.
And I am still not sure that the actual person (who has access to all the bits) has tried any of the connection scenarios I have suggested or not. I did stress some time ago that the TX and RX terminology with RS232 can be very confusing. Nowhere can I recall (and I am not going to waste time going back through the posts) seeing any confirmation of whether anything has been tried or what steps have been taken to logically isolate any problem.
And it is only just now I find out I have not been talking to the person who is having the problem.
Remote diagnosis can be difficult enough without having a 3rd party’s possible distortion. I stress that is not always the fault of the 3rd party as this person could be getting erroneous information in the first place but doing things this way is usually a good recipe for confusion.
I for one still don’t know now EXACTLY what the set up is. If the PoRa units are set up for RS232 that is what they will need. The Arduino WILL NOT output RS232. This is where converters will be needed. Same at the RX end. If the attached equipment will not handle RS232 the signal exiting the LoRa device will have to be converted to something the attached equipment will handle.
I have mad suggestions in the past about what pins should do what and what connections should work. If that has not been tried I can go no further. Maybe someone else is clairvoyant enough to try.
Cheers Bob
I’m Taylor, he’s Michael. I’m OP. We are not one and the same lol
1 Like
Hi Taylor.
Please excuse the confusion. Just a bit of Senile Decay, My fault. I just looked back to the start and it is indeed you who is having all the trouble.
When Michael replied It just got around to looking like him that was having all the trouble. I have just realised he is trying to sort things as was I but he purchased a system to have a play with.
Just where are you up to. Have you tried the connections I suggested (some could be addressed to Michael). Have stated before that the TX and RX terminology in RS232 can be confusing but some time ago I suggested a connection scenario that I think should work.
The Arduino will not output RS232, you need a converter.
The LoRa device will be RS232 (if configured that way) and should be considered a DCE device. That is once you hit the DE9 connector it is TX to TX and RX to RX.
Cheers Bob
Taylor, an add on.
Referring to the LoRa units.
The DE9 connector. The TX pin is actually the LoRa DATA INPUT to that device, that is the signal the DCE (Data Communication Equipment) device is going to Transmit to the receiving device.
At the Receiving end the Data comes out of the RX pin on the DE9. That is this is where you find the received data coming OUT of the DCE device.
1 Like
Hi Michael
Apologies. I must be losing it. Taylor just put me right. I was starting to consider you as the person having the trouble. I see now you are another trying to sort Taylor’s problem.
So it is me that is confused. Senile Decay.
Cheers Bob
2 Likes
Taylor, any chance I can get you to put your units into AT mode (+++) and get all your settings (including the version).
I hope to have a good play over the weekend.
Tonight’s test:
Powered up both units in their default settings (still on RS485). In this mode, I can connect to each unit in putty, and since putty is character based, it sends each character to the other unit as i type it. So for me, in all defaults, the stream mode seems to work as expected.
Over the weekend I want to tune the settings, move over to RS232 and retest.
Since you can get AT mode to work on each unit, that implies at some level the physical connection is OK. IF that is the case, then that suggests one or more of the settings is not correct/matched. e.g. encryption; so with a copy of your settings I can now review and test here.
Thanks
1 Like
