There are basically two methods to implement the SER12 receiver:
(a) Use the UART transmit interrupt to generate a periodical interrupt
with a higher rate than the radio baud rate, eg. 3 times the radio
baud rate, 3600 ints/s. Now sample the DCD line (that's where
the input signal comes in). From this information, you can recover
the bit clock (with some jitter) and the data. In order to
get the 3600 ints/s, you have to use the 6bits/character (+1 start
bit + 1 stop bit = 8 bits total) mode. This mode is not used
widely otherwise, everyone else needs 8 data bits/character.
That's why some chip manufacturers dropped the 6bits/char mode.
Another issue is that some UARTs don't like it if you change
the baud rate while they're transmitting, which is required
to synchronize to the received bit stream.
(b) Program the UART in Delta DCD mode, i.e. whenever the DCD line
changes. When an interrupt goes off, determine the system time
with high resolution, eg. under Liunx do_gettimeofday which gives
you almost us resolution. Now you can compare the time passed since
the last change of the DCD line, which gives you the number
of bits sent with equal value. This method relies on the Delta
DCD interrupt working properly, which reportedly does not work
reliably on some clones.
Traditionally, the Linux Baycom driver used (a). Driven by people
reporting success with TFPCX or other DOS software using method
(b) where (a) fails, I've changed the Linux Baycom driver to use
(b). I posted a patch on this list, but noone bothered to try it
out (at least I didn't get a single report), so I talked Linus into
putting it into the standard kernel to make people try it out :-)
Method (b) has other desireable features: it generates far less
interrupts (processing of interrupts incurs more overhead
the faster the processor is), its radio bit rate can easily be
changed (currently a compile time constant), and you get full duplex
for free :-)
What now makes me wonder is why transmitting fails. I could imagine
receiving to fail, but transmitting is, um, interesting. I'll
investigate this some time, but this may well take more than a month
since I have holiday shortly :-).
However you can restore the old behaviour:
Locate the following line in drivers/net/baycom.c
#define BAYCOM_ALT_SER12
and change it to
#undef BAYCOM_ALT_SER12
When I find out anything, I'd like you, Andrzej, and anyone
else using the baycom ser12 driver, to try it out and give me reports.
BTW, Andrzej, what does sethdlc -i bc0 -d tell you? Does P flash
when you try to send a packet? Does the tx packet counter
increment? What does the interrupt rate do?
73s
Tom