MAX BR1 Mini Serial Port


#1

Hello all,

This is my first time using peplink systems and hopefully you can give me a hand with the following problem:

I am experiencing troubles to stablish communication with a serial device that is behind the BR1 Mini/ACW-411 port adapter (a laptop running hyperterminal, so far).

I can reach the BR1 Mini form the LAN on the PEPLINK Balance 580 side to enter into the configuration interface of the remote BR1 Mini. I can also read the GPS stream from BR1 Mini port 60660 on a Putty telnet connection. But something (probably something stupid) I am missing or doing wrong in relation with the serial port or its configuration because I have failed so far sending/receiving data to/from the remote serial device (the laptop running hyperterminal) behind the BR1 Mini.

Wiring of the RJ45-DB9 cable was done according to the guidelines shared here in the forum by two different members. I am very familiar with serial communications, so serial configuration parameters on both sides, the BR1 and the terminal, are the same… The Putty TCP Client connects well to the IP/Port of the BR1 but nothing further happens at the serial port end when typing data.

If any of you guys have a comment or an idea to get me on the right track, that is appreciated in advance.

Thanks


#2

The first thing I would do is remove the laptop from the equation on the BR1 side (I’ll make the assumption that it is Windows based). Connect a router or switch to the console port instead and try to access it from the 580 side. I’ve never used the port adapter so I’m not sure how it is configured but I do know that Windows has a history of screwing with things if the settings/drivers are not right (like changing COM port numbers for no reason). If the router/switch responds, you know it’s something with the laptop and not the BR1 config. If the router/switch do not respond, you way want to look deeper at the BR1/adapter config.


#3

Have you come across this article that explains the OOBM example?


#4

Thank you both, Alan and goetzrc76, for your quick reply.

goetzrc76

I forgot to mention in my original post that I have actually done that exact test you suggested with good results. It was, in fact, the first validation test we did after setting everything up, using a Cisco switch (don’t remember the model now because I am out of the office) and it worked pretty well. After that, I assumed everything would go on easy with the serial port, but no…

Help me go further following your reasoning: if I take the laptop out (in fact, what I am planning to use on the serial side is a custom hardware I need to talk with from the TCP client on the 580 side, not any sort of PC) I assume that whatever I write on the putty terminal of the tcp client, once established the connection to BR1 IP/Port, should appear on the lines of the port. Is that correct?

I am originally a hardware guy. If that is correct I can just hook the lines of the port up to an oscilloscope and whatever happens in those lines I can electrically see it in the scope without intermediary Windows drivers, etc.

Alan

What I have done to configure my “serial device” (the laptop) looks very similar to the general procedure described in that link, but as far as I understand there is a big difference: I am not trying to connect it to the 580 console port. I am using it just as a serial terminal at the remote end, behind the BR1/Port Adapter, to catch what is written on the TCP client terminal, and reply back.

These are the references, very usefull, I have followed so far (one of them authored by you):



Looks strange to me by the way that, in the article referencd on the last link, the GND lines are not mentioned in the pinout.

Thanks again


#5

Would you mind to share more information about the serial terminal?

The BR1-Mini Console Adapter works like a Console Port for OOBM purpose, that follows the RS-232 standard.


#6

Sure. The final serial terminal will be a custom hardware able to communicate through a serial port, using RS-232 standard. I have been using the aforementioned laptop running Hyperterminal just for test purposes.

What I am trying to implement is a telemetry link between a PC on the 580 side and several BR1 on board same number of vehicles. The serial port of the BR1 will provide the final connection with our custom control board, which, upon request of the client PC, will provide status data of several variables of the car and execute some physical actions on it, like rising and lowering windows, etc.

We have assumed, hopefully not wrong, that this set up (the 580 plus the BR1s equiped with the port adapters) was adequate to provide the link we need. We need to have this serial channel operational, read the GPS stream (what we currently do) and provide WiFi capability to the car.

The first test done with the Console Port of a Cisco switch connected to the Port Adapter of the BR1 was a success. Whatever we typed on the Putty TCP client terminal (PC on the 580 side) reached the switch in real time, and its response was displayed back in the terminal the same way.


#7

Ok guys, this is just a quick update for those of you that have been following this thread.

1- Based on the test aforementioned using a Cisco 1841 Console port, I verified by hardware that only Rx, Tx and GND signals connect the Port Adapter and the Console Port. Just that, so no handshaking signals of any type are involved in the link. From the hardware point of view, this is the simplest asynchronous serial scenario we could expect/desire.

2- Based on the previous fact and following the reasoning of goetzrc76, I removed everything on the remote end and hardware configured the port in loopback mode (a jumper between TX and RX lines). According to this set up, whatever is received on the Rx line comming from TCP Client will be returned back to it, being displayed twice on the Putty terminal screen.

Well, it works.!

The problem so far is that it works only sometimes, but not always.

When it works, whatever I type returns back and is displayed twice, as expected. Sometimes, if I open the loopback jumper and restore it again, it stops working. After a while, it works again. Some times, while stopped, the disconnection of the loopback jumper is what makes it work again. I have not identified a pattern on this, yet.

Any idea?

Thanks


#8

These are just thoughts, for the record. I will go back to this next week because of the Christmas holydays, but based in the fact that the Cisco console RS232 port and the BR1 Mini RS232 port work pretty well together, but not the BR1 Mini with the USB-RS232 Converter hooked to the laptop, a final test yesterday lead me to compare the voltage levels of the output pins on both, Console port and Converter port, trying to find something diferent.

These are the results:

Cisco console RS 232 Tx pin level: -11.0 volts
USB-RS 232 converter Tx pin level: - 5.0 volts

Don’t know, yet, if this could be cause of the extrange behaviour described in my previous post or not because, technically, both meet the RS-232 standard. But on the other hand, it is obvious that Cisco RS232 driver meets the standard in a greater degree than the USB converter. So…

  • If, for some reason, the BR1 port input has voltage thresholds greater than +/-5V, then it will never “see” the swing on the USB converter output as a valid logic change. This could explain why, when typing on the Hyperteminal, nothing is received at the other side.

  • Not clear for me, so far, how could this affect the communication in the opposite direction. A greater voltage swing presented by the BR1 Mini output ant the input of the USB Converter (having some +/-4V threshold) should be “seen” for sure, and received at the Hyperterminal end. But it doesn’t happen…:face_with_raised_eyebrow:

The case remains open.If you have any idea to share, it is welcomed and appreciated.


#9

@armr, can you open a support ticket here with reference to this thread, so we can take a closer look at your setup?

If you can include a network diagram to illustrate your setup, that will be much appreciated.


#10

Hi.
Please could you post to this thread what the eventual findings were?
Thanks!