Has anybody tried using a asynchronous, i.e. poll() based i/o, to handle
bidirectional data transfers over a USB-serial adapter?
I have a setup that works as expected when talking to a program that
emulates the target via a socket session, but appears to send but not
receive messages when connected to the target device via a USB-serial
I know the USB adapter works when used to connect the same laptop to a
PICAXE chip: compiled programs get loaded into the PICAXE and output is
received when the program runs. Its the AXE027 adapter sold by PICAXE.
FWIW the target device is a Dittel KRT2 airband tranceiver. I need to use
its serial interface to load sets of preset frequencies into it or to
retrieve the presets and save them as backup files.
On a sunny day (Fri, 18 May 2018 00:13:32 +0000 (UTC)) it happened Martin
Gregorie wrote in :
If I am understanding you right? You just want to talk to a /dev/ttyUSBX ?
Here is a simple example, my serial commie-nuke-aid-ion program:
C code, uses 'select()'.
If you look at the functon set_port_parameters() in that code, it sets the required baudrate using stty,
so you could even script that,
I never use poll(), select() does everything and more.
You find those select() based commie-nuke-aid-ion solutions in many programs I wrote on that link.
For the rest USB sucks.
As an alternative after setting the baudrate with for example
stty -F /dev/ttyUSBX -N 115200
you could write to a serial USB device with
cat /dev/ttyUSBX > filename
and write to it with
cat filename > /dev/ttyUSBX
ptlrc has a script mode, never used it for years, so YMMV.
but it is the best commie-nuke-aid-ion program around,
wrote it to commie-nuke-aid with Microchip PIC devides, works on anything else.
Not the catch that Unix use LF as line termination,
while many other systems need the extra CR, so need CRLF:
/* PIC wants CR */
if(tx_buffer[i] == 10) tx_buffer[i] = 13;
if(tx_buffer[i] == 13)
tx_buffer[i + 1] = 10; // CR
Also note the lines:
system("stty -echo"); /* no echo */
in the ptlrc code, also system calls to stty
maybe not important for your app if you do not emulate a teminal
Code is GPL.
Does this help, tick as required:
[ ] Yes
[ ] No
[ ] Dunno
[ ] Help
click to reset your computer.
Not personally but one of our products presents as a USB serial adapter
so I have good reason to believe that it works in general.
1) strace your program to get some visibility of what?s going on.
2) See if it works with blocking IO (no poll).
There aren't any: the AXE027 USB-serial adapter uses a three wire
connection terminated by a 3.5mm stereo jackplug. I know that's working
correctly because using it lets a RaspberryPi interact with a PICAXE chip
and I have checked that the connections between the KRT2 and a 3.5mm
socket on my panel are good and connect the appropriate pin on the KTR2
to the expected jack segment.
This is why I asking about the adapter's compatiblity with async i/o
managed by poll().
This is probably very close to a saying involving Grandmas and eggs
Is the KRT2 also a three wire device (Tx, Rx, Gnd)? Or does it expect
to see any handshake lines? Though TBH I wouldn't expect it to work
in either direction if it expected hardware handshake.
As the AXE027 is designed for a PICAXE is it using TTL 0 - 5 V signal
levels or proper RS232 +/- 12 V? What does the KRT2 expect?
Can you monitor the Tx and Rx an lines and see if data is being sent
on either. A LED with series resistor from each line to Gnd will do.
Once you know that the hardware is playing you know for certain that
you have a software problem of some sort.
On a sunny day (Sat, 19 May 2018 11:31:11 +0000 (UTC)) it happened Martin
Gregorie wrote in :
If you use the ptlrc commie-nuke-aid-ion program
just connect tx and rx together at the other end and type something,
should echo each character, confirms that your side is working.
Important is to get the BAUDRATE correct.
Often programs send some sort of hello message on powerup.
So see if anything happens in ptlrc when powering up that thing.
If it is unreadable try an other baudrate, and repeat.
Sometimes simply typing 'help' gets a response,
cracked a big expensive thing that way.
And finally, you DO use the right /dev/ttyUSBX ?
insert the serial adaptor
it should show a new entry in /dev/ttyUSBX,
where X is the device number.
Or check with:
ls -rtl /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 1 May 13 13:25 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 0 May 19 08:13 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 2 May 19 14:37 /dev/ttyUSB2
Use last one
ptlrc -d /dev/ttyUSBx -b 19200???
Yes, it is.
Good point and one I didn't think of but should have - I'm too used to
stuff that works on either TTL or 12v.
The AXE027 is almost certainly TTL level since PICAXE chips are happy on
nominal 4.5v supplies (3 x AA cells).
The KRT2 manuals don't say what signal levels are expected on the serial
port. The radio runs off 9-28v (mine is on a 12v SLA) but the manuals say
nothing about serial port levels. It is (used for both presets up/down
load and to connect to an optional remote control head). The manuals I
have include one for the presets up/download connection, but that expects
the PC to have an RS-232 serial port and, again, doesn't mention the
expected signal level.
Thats difficult logistically, but I think I can get a scope on the lines,
which may be easier than powering a logic probe or adding LEDs. The logic
probe would be my favoured weapon but I'm not sure where I'd get its
power from in this case. The KRT2 crams all its connections onto a D-15
and the resulting cable connections (power, PTT, mic, speaker, serial
lines) have filled its cover to bursting point).
If needed, I have another USB adapter but its an older pfranc unit and I
don't know what its serial signal levels are either. USB-serial adapters
are obviously running off 5v, but do they normally provide 12v or TTL
levels on their RS232 pins?
Anyway, thanks for pointing out an obvious point I'd overlooked.
I'll ask the local agent about signal levels on Monday.
On a sunny day (Sat, 19 May 2018 13:39:39 +0000 (UTC)) it happened Martin
Gregorie wrote in :
If it has a D connector then it very likely will output RS232 compatible signals.
I have both, (with D connector) and a with logic level output pins.
Note that it is not only that voltage level, the ones with logic level outputs are INVERTED,
so high level is low level etc. compared to real RS232 (D connector).
The ones with logic level output will interface directly with a microprocessor,
the D connecetor RS232 ones need a MAX232 chip or equivalent to interface with a microprocessor.
MAX232 was the standard interface chip in the old days,
it generates its own + and - higher voltage from 5V. and inverts the signal back,
You need a real one with D connector for that thing you want to interface.
And some times devices aren't too fussy and work anyway...
I'd expect a PC RS232 port to be +/- 12 V.
And will give you a definative on the levels, that LEDs or logic
Ones proporting to be "RS232" rather than just "serial" ought to
provide +/- 12 V.
Thanks for that. With Rx and TX shorted together at the stereo jack the
AXE027 adapter cable is successfully echoing test strings back through
ptlrc - so the cable is working. This works both on my RPi B (original
512KB version, Raspbian) and on my Lenovo T440 (Fedora 27).
However, that form of loopback isn't working with my code. so I've
probably got the serial port bit settings wrong, since the code works
correctly when talking to a target emulation program over a socket
On your code it loopback works OK at both 4800 and 9600 baud.
I'm still going to talk to the Dittel agents about the KRT2 signal levels.
In the meantime I'll review my serial port settings in comparison with
yours. This is a little puzzling, though because a while back I had the
port handler working well when driven by a glass teletype emulator
written in Java and using a real RS232 port connected to a system running
Microware's OS/9 at 9600 baud, so it looks as though I'm using port
options that worked with a full RS232 cable but not on a 3-wire link.
Indeed, though its drivers need to be configured after connection to the
host and before attempting to connect to it - otherwise its simply not
On a sunny day (Sat, 19 May 2018 18:05:22 +0000 (UTC)) it happened Martin
Gregorie wrote in :
Yes, but I mean the baudrate of that thing you are connected to,
You need to know what speed that is.
There are devices thar will autmatically detect baudrate, and
then send back at the same speed, but that is not very common.
In an other reply I mentioned the difference between RS232
and the USB to logic level adaptors,
the ones with RS232 (D connector such as that Dittel thing you want to connect to)
use inverted logic, also those drive the signal negative,
not sure your logic level interface will stand that.
I was thinking if I was in the boonies and had no other option
and HAD to use the non inverting cable and IF it did not blow up on real RS232 signals on its input,
then MAYBE I would xor ptlrc output bytes with 0xff and same for input bytes to force the invert ;-)
I thought I'd mentioned that earlier: 9600, no parity, 1 stop bit and
setting that is already taken care of.
As I said - I'll talk to the agents next week. They're friendly and
If RS-232 levels are needed, its easy enough to make up a three wire
cable for a RS-232-level USB adapter with a 3.5mm stereo jack on the end.
I started with the AXE027 adapter because I already have one.
Today I used a screwdriver to short the segments. Its also easy enough to
short the connections on spare socket and hang the scope on that to check
whether the signal is inverted or not.
On Sat, 19 May 2018 18:54:26 GMT, Jan Panteltje
declaimed the following:
Unless you are bit-banging a GPIO, that won't work... 8-bit data is
sent as 10+ bits by a UART.
1 start bit
8 data bits
1+ stop bit (some devices required up to two bit times before they could
handle a new start bit.
You'd be inverting the 8 data bits, but not the start/stop bits. Stop
bits are whatever the protocol considers as an idle state (pull up or pull
down, so when the UART is not doing anything, the line shows a stop bit.
Start bit is the inverse of a stop bit -- basically a forced level
transition to wake up the receiver UART, since the first data bit could be
the same state as a stop bit.
Wulfraed Dennis Lee Bieber AF6VN
On a sunny day (Sat, 19 May 2018 18:54:26 GMT) it happened Jan Panteltje
wrote in :
Actually that won't work, as you also need to flip start and stop bits, not just the data.
One could write a software UART (done it) but that won't work in Linux due to the taskswitch interrupt.
You need a real USB to RS232 adaptor.
It ought to as the port is listening at the same rate as it's sending
at and at the correct levels and polarity.
The AXE027 is a TTL device (GIYF). Previously you've said the KRT2 is
designed to work with a PC RS232 serial port so the odds are it is
expecting +/- 12 V RS232.
IIRC the RS232 spec does have the signals inverted on the wire but as
it's the spec it's not relevant to two RS232 devices talking to each
other. How ever if the PICAXE adapter is TTL it probably isn't
inverted and the levels are wrong (though some RS232 ports aren't
that fussy about levels).
The quickest and simplest solution is if you have a known USB > RS232
adapter try that. If it has a D type connector it probably is RS232,
check by measuring the voltage on the Txd pin with it powered up 12 V
(+ or -) means RS232. Otherwise you need to invert the Tx and Rx
lines from the AXE027 at TTL levels and hope the KRT2 doesn't demand
+/- 12 V and what ever you use to do the Rx inversion can tolerate
being driven to -12. Two transistors and a handful of R's? Power for
this inversion circuitry is an issue as you can't "borrow" from the
hardware handshake lines... Get a proper USB > RS232 adapter. B-)
Well, after some other distractions plus an uncharacteristically slow
delivery of some bits from Rapid (Scopebanana plug cable, additional
3.5mm plugs&sockets, I lashed up a terminator box for the AXE027 cable
with Rx-Tx shorting switch and 4mm plugs for instrument connection.
Then I used ptlrc running on my RPi 1+ B to run some tests. Everything
was as expected - including adapter's output, which is just over 4v
according to my 'scope, a fairly old Hameg 203s. Making ptlrc send its
LICENSE file gave several seconds of output - enough to make reading the
scope easy (it wasn't visible from my keyboard).
No word from the Dittel agents, so next job is to make up a D-9 to 3.5mm
stereo jack cable, test, and check the levels from my pFranc serial
adapter before trying it on the Dittel radio.