Can you try this settings?
DB9 Pin 5 (Ground) → RJ45 Pin 5 (Ground) – Grounding is important
DB9 Pin 3 (Tx) → RJ45 Pin 2 (Rx)
DB9 Pin 2 (Rx) → RJ45 Pin 3 (Tx)
And then try with the crossover for the DB9
Nothing has worked yet, unfortunately.
I am wondering how important it is that all of the other pins are connected or covered in some way. Can they cause issues if left loose inside the adapter?
Have you considered this?
How are you testing? Are you testing with the device connected directly to a PC running a terminal (ie: putty).
Did you find the correct serial parameters for your device like the baud rate, flow control, stop bits, etc…?
Yes.
I have that info from global cache. And, I always try swapping the rx/tx with whichever pin combo I’m testing.
@Jdamore - I’m using the Global Cache iTest app.
The device (now an iTach WF2SL) is directly connected to the control box for the screen masking.
I have confirmed baud rate and other settings match what is required (Had to buy a new iTach since my old GC-100-12 topped out at 57.6k rate)
I ended up having an issue with one of the motors on the masking and had to have the manufacturer send someone down to my house (I’m about 5 hours away from where they are) to replace them.
They finally came out this weekend, and while they were here I was able to test their cable out and got it to work, but didn’t get the time to really dig into the cable and how they had things. They used a more complex solution than I was going with.
However, yesterday, I was able to use a multimeter to determine exactly which pins matched up correctly and mapped them appropriately. So, I have it currently working with the iTach itest app. Now, I just need to implement it in my home remote design.
1 Like
Could you share the final pin-out setup?
Sure.
So it was, using a T-568B cat-6 cable, orange pin to 2 (Rx), black pin to 3 (Tx), and green pin to 5 (ground).
It may differ based on the brand of adapter purchased. But, the RJ45 pins to the color pins of the adapter were:
1 - Blue
2 - Orange
3 - Black
4 - Red
5 - Green
6 - Yellow
7 - Brown
8 - White
So, basically I just had to pass them straight through, RJ45 2 to DB9 2, RJ45 3 to DB9 3, and RJ45 5 to DB9 5.
Unfortunately, I’m still not having a lot of success.
The control box for the screen seems to be very finicky and if it’s not getting everything exactly how it wants, it crashes and becomes completely unresponsive. This forces me to restart it, which the only (or rather by far the easiest) way to do is to flip a breaker on the electrical panel as the box is behind the screen in my false wall.
Sometimes this works and I can regain control, at least with a direct connection to the control box’s internal wifi network. Though, usually it takes me 2 or 3 times of restarting before it becomes responsive. If it does start working again, I can sometimes use iTest to send commands and it works. But it seems less and less reliable. It may work on one command, and then the next one crashes it.
Once, and only once, was I able to send a command successfully with The Home Remote designer. I was happy to see the masking in place where I expected (hoped) it would be and thought my ordeal was finally over and I’d be able to finally control my screen. Unfortunately, it has never worked through The Home Remote since, and minimally with the other methods.
For being a $5k+ screen, and paying extra for the RS232 functionality, I had definitely hoped for something more reliable.
I don’t know if there still some trick I’m missing, but I don’t feel it should be this inconsistent and delicate.
I’m not sure if I need to be sending a carriage return in my command or not. I haven’t seen mention of it anywhere, and have had iTest work with and without. And of course, the one time it did work with The Home Remote, it didn’t have anything for it in the command I sent.
Success!
It’s now working consistently with THR. I was sending ASCII string commands for the most part. That is how the web interface on the control box accepts commands. But, I changed it up and made everything hex and it is liking that much better.
They also told me, that if I need to do a power-cycle to reset it, that I need to do 2. That has helped with the consistency.
Now, I just need to figure out the receive method on the tcpClient to get the status. The available property shows 5 bytes in the buffer, but when I try to read that into a variable, it tells me it’s undefined.
Do I need to accept it differently since it’s coming as byte data, and not a string?