YAM modems at higher (shared) IRQ's

YAM modems at higher (shared) IRQ's

[Curt, WE7U]

I haven't seen a lot of activity on the mailing lists for a while about YAM modems, but I just got handed a couple of them and I'd
like to put them to use.

I've successfully configured a YAM on a laptop w/OpenSUSE-11.3 32bit, but cannot on a desktop running OpenSUSE-11.3 64bit.  The
desktop has a Startech 4-port PCI card (with 16550's on it) at /dev/tty4 through 7 at odd addresses and a shared IRQ 17.  The
laptop has one /dev/ttyS0 port at the standard address and IRQ.


Laptop config, appears to work but is not hooked to a radio yet.  The red LED blinks when I do a ping:

     /sbin/modprobe -a yam
     /bin/setserial /dev/ttyS0 uart none
     /usr/sbin/yamcfg yam0 io 0x3f8 irq 4 pers 128 txd 150 bitrate 9600 baudrate 9600
     /sbin/ifconfig yam0 44.24.102.128 netmask 255.255.255.0 mtu 256 hw ax25 WE7U-3 up


Desktop config, doesn't work:

     modprobe -a yam
     setserial /dev/ttyS7 uart none
     yamcfg yam0 io 0xd880 irq 17 pers 128 txd 150 bitrate 9600 baudrate 9600
     /sbin/ifconfig yam0 44.24.102.128 netmask 255.255.255.0 hw


I get this for the desktop config at the "yamcfg" stage:

     yamcfg yam0 io 0xd880 irq 17 pers 128 txd 150 bitrate 9600 baudrate 9600

     yamcfg: Version 0.1 (C) 1998 by Jean-Paul ROUBELAT - F6FBB

     yamcfg: Error Invalid argument (22), cannot ioctl SIOCYAMSCFG on yam0


Using only "yamcfg yam0 io 0xd880 irq 17" I get the same error, but "yamcfg yam0 io 0xd880" works (but IRQ is set to 0 in that case).

I believe the problem is the shared IRQ 17.  "yam.h" appears to reserve one character position for the IRQ, so can't use IRQ's
above 9.  Correct?

I'm attempting to fetch kernel sources but the repositories appear to be unavailable.  Once I have them I'll try to code around the
problem.

If anyone has any ideas or pointers on how to fix this, please let me know.  Thanks!

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
Babysitting your tracker:  http://info.aprs.net/index.php?title=ControlOperator

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

On Sun, 6 Mar 2011, Curt, WE7U wrote:

> Desktop config, doesn't work:
>
>    modprobe -a yam
>    setserial /dev/ttyS7 uart none
>    yamcfg yam0 io 0xd880 irq 17 pers 128 txd 150 bitrate 9600 baudrate 9600
>    /sbin/ifconfig yam0 44.24.102.128 netmask 255.255.255.0 hw

Finally got the kernel sources and I see this:

         if (!dev->base_addr || dev->base_addr > 0x1000 - YAM_EXTENT ||
                 dev->irq < 2 || dev->irq > 15) {
                 return -ENXIO;
         }

Which means any IRQ above 15 is going to be rejected by the YAM driver.  I'm recompiling the YAM module now with a "> 99" tweak to
see if I can get one or two YAM's working with the 4-port Startech card.  I'll post my results.

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
APRS Wiki:  http://info.aprs.net/

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

On Mon, 7 Mar 2011, Ray Wells wrote:

> I did find this on an yam old mailing list ...
>
> *"Other problem f3kt cannot use yamser with a irq superior has 4."
>
> *http://sharon.esrac.ele.tue.nl/pub/packet/yam/guestbook.htm
> *
> *Jean-Paul, F6FBB recently appeared on the FBB mailing list; maybe he can 
> shed some light.

Roger.  I sent him similar messages and they didn't bounce (yet), so he may yet answer.  I'm not sure what f3kt is.

I tweaked yam.c in two places to allow IRQ's up to 99, then compiled and used the new driver.  Doing this:
---------------------------------------------------------------------
     /sbin/modprobe -a yam
     /bin/setserial /dev/ttyS5 uart none
     /usr/sbin/yamcfg yam1 io 0xd880 irq 17 pers 128 txd 150 bitrate 9600 baudrate 9600
     /sbin/ifconfig yam1 mtu 256 hw ax25 WE7U-5
     /sbin/ifconfig yam1 44.24.102.128 netmask 255.255.255.0
     #/sbin/ifconfig yam1 up
---------------------------------------------------------------------

I now get this:
---------------------------------------------------------------------
     # ./yam.up

     /usr/sbin/yamcfg: Version 0.1 (C) 1998 by Jean-Paul ROUBELAT - F6FBB

     Device    : yam1
     iobase    :*d880
     bitrate   :*9600 (bps)
     irq       :*17
     baudrate  :*9600 (bps)
     fulldup   : off
     txdelay   :*150 (ms)
     txtail    : 10  (ms)
     slottime  : 100 (ms)
     persist   :*128

     SIOCSIFFLAGS: No such device or address
---------------------------------------------------------------------

So...  I'm one step closer.  It has accepted IRQ 17 but has trouble with setting IP address and netmask.

Again, I'm able to configure _one_ YAM modem on a laptop just fine, but it's this four-port PCI card in the desktop that I need to get going.  Once I get one YAM running I'll want to configure a second.

Ideas?

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
APRS:  Where it's at!        http://www.xastir.org

Re: YAM modems at higher (shared) IRQ's

[walter harms]

Am 07.03.2011 07:22, schrieb Curt, WE7U:
> On Mon, 7 Mar 2011, Ray Wells wrote:
> 
>> I did find this on an yam old mailing list ...
>>
>> *"Other problem f3kt cannot use yamser with a irq superior has 4."
>>
>> *http://sharon.esrac.ele.tue.nl/pub/packet/yam/guestbook.htm
>> *
>> *Jean-Paul, F6FBB recently appeared on the FBB mailing list; maybe he
>> can shed some light.
> 
> Roger.  I sent him similar messages and they didn't bounce (yet), so he
> may yet answer.  I'm not sure what f3kt is.
> 
> I tweaked yam.c in two places to allow IRQ's up to 99, then compiled and
> used the new driver.  Doing this:
> ---------------------------------------------------------------------
>     /sbin/modprobe -a yam
>     /bin/setserial /dev/ttyS5 uart none
>     /usr/sbin/yamcfg yam1 io 0xd880 irq 17 pers 128 txd 150 bitrate 9600
> baudrate 9600
>     /sbin/ifconfig yam1 mtu 256 hw ax25 WE7U-5
>     /sbin/ifconfig yam1 44.24.102.128 netmask 255.255.255.0
>     #/sbin/ifconfig yam1 up
> ---------------------------------------------------------------------


can you try to switch  /bin/setserial & /sbin/modprobe  ?
maybe some ttyS driver allocates /dev/ttyS5.

re,
 wh

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

On Tue, 8 Mar 2011, Ray Wells wrote:

> Have you tried running KISS TNC's off the four port to prove it provides 
> working standard com ports?

Yes.  I'm running a TNC-X using the ax25 and mkiss modules, creating the AX.25 port called "aprs" that I'm feeding Xastir with.

I killed everything on that port and tried it with a YAM as well.  No change.


> It was a while back now and the memory is dim but I was getting strange 
> errors and performance with a very old Australian made four port ISA card 
> with shared IRQ. In my case I had to guess addresses due to lack of 
> documentation. From memory, acpi was a problem at one stage, wanting to grab 
> the IRQ that was set up as Legacy in BIOS for the four port.
>
> FWIW, here's my four port configd
>
>    /bin/setserial -v /dev/ttyS0 uart 16550A port 0x180 irq 3 fourport
>    /bin/setserial -v /dev/ttyS1 uart 16550A port 0x188 irq 3 fourport
>    /bin/setserial -v /dev/ttyS2 uart 16550A port 0x190 irq 3 fourport
>    /bin/setserial -v /dev/ttyS3 uart 16550A port 0x198 irq 3 fourport

setserial shows these are all 16550's and shows reasonable numbers, but the base addresses and IRQ's are much higher than you can have with an ISA card.  I've made tweaks to "yam.c" to compensate for the higher address and IRQ.  The IRQ change got me further towards getting things configured but I'm not quite there yet.  Perhaps the base address problem needs tweaks in other places besides yam.c to make it functional.

If I don't get them working soon I may build some G4XYW modems instead.

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
Babysitting your tracker:  http://info.aprs.net/index.php?title=ControlOperator

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

On Mon, 7 Mar 2011, walter harms wrote:

> can you try to switch  /bin/setserial & /sbin/modprobe  ?
> maybe some ttyS driver allocates /dev/ttyS5.

Worth a shot.  Same results.

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
Babysitting your tracker:  http://info.aprs.net/index.php?title=ControlOperator

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

I got farther last night!  It helped that I could configure one on the laptop (with one _standard_ serial port) and see what the LED's were doing on the YAM, then try it on the desktop and notice the differences.

To recap:  I can make one YAM work on the laptop, but that's not the final destination.  I haven't gotten one to work on the desktop yet, but want to get two YAM's working there as well as a couple of other TNC's.

     Laptop                  Desktop
     ------                  -------
     OpenSuSE-11.3 32-bit    OpenSuSE-11.3 64-bit
     Qty 1 - 16550a          Qty 4 - 16550a
     I/O: 0x3f8              I/O: 0xdc00 (and others slightly below)
     irq 4                   irq 17 (shared)

At the point I do an "ifconfig up" on the laptop I see one LED go nuts on the YAM for a few seconds as the Xilinx chip is being loaded.  Last night I was finally able to see that on the desktop, but then the command errored out upon finishing the loading.  This is progress though as I've not seen the Xilinx get loaded via the desktop until last night.

I've been hacking on the "yam.c" code.  I've changed the high-range check for IRQ's to "< 99" (was "< 15") and removed the high-range check for the base address (was 0x1000 - extents).  Last night I rummaged through the code some more and noticed variables in "yam.h" that were defined as "unsigned int" but used in "yam.c" as "int".  By switching the I/O base address to "unsigned int" I finally got the LED blinking that shows the Xilinx is being loaded.

What I've learned so far:

*) The kernel driver hasn't been updated to handle IRQ's and I/O addresses which are commonplace with PCI serial cards.
*) Sign problems exist between the .h and the .c files.
*) There may be 64-bit issues as "int" and "unsigned int" shouldn't be used in portable code:  Should use UINT8, UINT16, UINT32, etc instead.

I believe I've fixed the first two but the third needs to be done yet.  The switch from "int" to "unsigned int" was just a first approximation but is not the correct fix for portability.

Anyone willing to help with portability tweaks to the code please jump in here!  I'll provide a patch if/when I get it working.

NOTE:  It would be worthwhile to look through some of the other "drivers/net/hamradio/" code for similar problems with other AX.25 drivers.  The Baycom driver most likely suffers from similar problems (the YAM driver was derived from it) unless it has had more use recently and therefore has had more recent fixes than the YAM driver.  If other drivers have not been touched since the ISA days, or even the pre-64-bit days, they will need some of the fixes applied as well.

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
Babysitting your tracker:  http://info.aprs.net/index.php?title=ControlOperator

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

On Tue, 8 Mar 2011, Curt, WE7U wrote:

> To recap:  I can make one YAM work on the laptop, but that's not the final 
> destination.  I haven't gotten one to work on the desktop yet, but want to 
> get two YAM's working there as well as a couple of other TNC's.
>
>    Laptop                  Desktop
>    ------                  -------
>    OpenSuSE-11.3 32-bit    OpenSuSE-11.3 64-bit
>    Qty 1 - 16550a          Qty 4 - 16550a
>    I/O: 0x3f8              I/O: 0xdc00 (and others slightly below)
>    irq 4                   irq 17 (shared)
>
> At the point I do an "ifconfig up" on the laptop I see one LED go nuts on the 
> YAM for a few seconds as the Xilinx chip is being loaded.  Last night I was 
> finally able to see that on the desktop, but then the command errored out 
> upon finishing the loading.  This is progress though as I've not seen the 
> Xilinx get loaded via the desktop until last night.

What I found out:  The 16550 interface that I was trying to get running... ain't.  It's a 16550-compatible multi-port card, NOT a card with 16550A's.  I may not be able to get it working, depending on how compatible the chip is and how the board is wired.  It's a Startech 4-port card with a NetMos Technology 9845 chip.

Worse, I examined the 2-port cards I have:  They're also 16550-compatibles (SYBA 2-port PCI cards).  I didn't get a chance last night to swap out the 4-port for one of those to see if they do better talking to the YAM.

In my spare parts I found one PCI card with a real 16550A, a single-port card.  Newegg has LAVA 4-port ($76) and 8-port ($111) cards w/real 16550A's if I want to go that route.  Most of the cards I see offered for sale are 16550 "compatible".  Anything that does faster than 115200 baud appears to be a "compatible" instead of a real 16550A.  Cards with real 16552's or 16554's should work fine assuming all the lines for a DE-9 are wired out to the connector and controllable by the chip.  That LAVA 8-port has the "RI" signal wired out to only the first four ports.

I'm deciding whether to go further down this rabbit-hole attempting to get non-16550A cards to talk to the YAM.  Changes to date are useful to fold back into the mainstream, updating the driver to modern standards and increasing portability.  Additional work to get "compatible" boards to talk to the YAM may not be a good use of my time.

This is the 4-port card, using "lspci -v" to get the info:

     01:06.0 Serial controller: NetMos Technology PCI 9845 Multi-I/O Controller (rev 01) (prog-if 02 [16550])
             Subsystem: LSI Logic / Symbios Logic 0P4S (4 port 16550A serial card)
             Flags: medium devsel, IRQ 17
             I/O ports at dc00 [size=8]
             I/O ports at d880 [size=8]
             I/O ports at d800 [size=8]
             I/O ports at d480 [size=8]
             I/O ports at d400 [size=8]
             I/O ports at d080 [size=16]
             Kernel driver in use: serial

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
APRS:  Where it's at!        http://www.xastir.org

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

On Wed, 9 Mar 2011, Curt, WE7U wrote:

> What I found out:  The 16550 interface that I was trying to get running... 
> ain't.  It's a 16550-compatible multi-port card, NOT a card with 16550A's.

> Worse, I examined the 2-port cards I have:  They're also 16550-compatibles 
> (SYBA 2-port PCI cards).

> In my spare parts I found one PCI card with a real 16550A, a single-port 
> card.

The motherboard also has one serial port but the 10-pin ribbon w/attached DE-9 and bracket didn't come with it.  I went hunting tonight to find one that would work and just tested out that port also.

Latest finds:
-------------

*) NO-WORKY:  SYBA SD-PCI-2S 2-port serial PCI cards (NetMos Technology MCS9835CV chip).  I have two of these cards.  They claim to be 16550A-compatible.

*) NO-WORKY:  Startech PCI-4S-550N 4-port serial PCI cards with the NetMos Technology MCS9845 chip.  I have one of these cards.  They claim to be 16550A-compatible.

*) WORKS:  SIIG FastSerial IO1829 16550A 1-port serial PCI card.  If I had a lot of PCI slots I'd just buy a bunch of these as they're very cheap on Ebay right now ($5).

*) WORKS:  ASUS M3N78-VM motherboard serial port (16550A-compatible, integrated inside the NVidia chipset on the motherboard).

I needed my tweaks to the yam driver in order to use the SIIG card, as it showed up at a high interrupt and with high I/O addresses.  It worked fine talking to the YAM from my OpenSUSE-11.3 64-bit system, as did the motherboard serial port.  These experiments lay to rest the 32-bit vs. 64-bit issue as I've successfully configured a YAM modem on both 32-bit and 64-bit Linuxes now.

The remaining question:  Is it possible to get the NetMos chips to configure the YAM's?

There must be a difference in the chips "loopback" mode between the above cards.  The driver takes the chip into loopback mode, then bit-twiddles two lines (TXD and RTS) to create the synchronous CLOCK and DATA lines for loading the Xilinx chip.  Real 16550's and the one inside the motherboard chipset are able to do this, but the NetMos Technology 9835/9845 chips cannot.

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
Additional pages:  http://wetnet.net/~we7u

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

This is where I found out about the G4XYW G3RUH-compatibile 9600-baud modem, and the paper is an excellent find in itself:

     "Evaluation of microcontroller based packet radio modem"

which I found by doing a Google search for "9600 g3ruh" and other modem terms.  Add "g4xyw" to the search (or of course the title above) to find the paper more quickly.

A 3dB improvement over the G3RUH modem is what is claimed.

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
APRS in Search and Rescue:  http://wetnet.net/~we7u/search_and_rescue.html

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

I'm about done WRT further progress on the YAM driver, at least for now.  I'm getting ancy to get something on the air, so have a 220 MHz mobile rig in to work with me today to redo the
coax taps, then will hook it to one of:  YAM / PK-232 / DSP-232.  I can get one YAM going reliably on the motherboard serial port, then with the 4-port board talking to various TNC's I
can do the other 1200 and 9600-baud links I want to do for now.

As of last night I can get one of the YAM's configured every time on the motherboard's serial port, but never using the 9835/9845 cards.  The second YAM board is being finicky in all cases but I don't know if it's the driver or the board.

I tweaked the driver yesterday to better supply power to the board.  During programming the PWR LED stays lit now instead of flashing, and that LED is always on nice and strong.  Power is supplied via two handshake lines that need to be at opposite states to keep +12V/-12V supplied.  One of those is used during programming and also controls PTT.  Weird, but some people do anything to save a buck.  I've seen worse!

I may add a function to the driver for controlling the two handshakes so that they are always kept at opposite states.  Right now it's all done with bit-twiddling of both lines on the spot, and you have to keep the opposite-states thing in mind while tweaking any of those spots.

Also:  I was wrong about the driver using UART loopback mode during operation.  It only uses loopback mode to decide what sort of UART is out there, then switches back to normal operation.  The trick they're doing in order to accomplish synchronous programming of the Xilinx:  They set the data line (RTS in this case), then throw $0xFC into the transmit buffer which causes this bit pattern to be sent out on the CLOCK line:

     1 1111 1100 0

That first 1 is a start bit, then 8 bits of data, then a stop bit.  This produces a nice clock pulse to program the data bit into the Xilinx with.  Not a bad trick to use an asynchronous port to do synchronous programming of a part.

Another thing I found out yesterday is that there's a v1.7 YAM and a v1.10 YAM.  I have two v1.10b boards.  They require different MCS firmware loads because Xilinx pins have been moved and the board layout has been changed.  I don't know which firmware is in the Linux driver now.  It would be nice to have that documented and the firmware added to the kernel so people would
know to choose the proper one for their board.  The driver appears to have the capability to use an alternate file, but there aren't any alternate files to be had in the kernel.  I just found an MCS file for the v1.10 board, but it's just a single one, so they might have combined the 1200 and the 9600 baud circuits into one now.  How they are chosen via software is something I have yet to figure out.

Any pointers as to who to submit the patches to?  Probably the kernel-hackers list?  How to submit them?  It might be a few more days or weeks before I get around to it though.  I've tested the driver on 64-bit and 32-bit, but will do so again before I send any patches upstream.

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.

Re: YAM modems at higher (shared) IRQ's

[Robin Gilks]

>
> This is where I found out about the G4XYW G3RUH-compatibile 9600-baud
> modem, and the paper is an excellent find in itself:
>
>      "Evaluation of microcontroller based packet radio modem"
>
> which I found by doing a Google search for "9600 g3ruh" and other modem
> terms.  Add "g4xyw" to the search (or of course the title above) to find
> the paper more quickly.
>
> A 3dB improvement over the G3RUH modem is what is claimed.

Wow - here is someone who spent more time analysing mine and Andy/g4xyw's
work than we put into it in the first place by the looks of it.

Who would have thought that an exercise in using AVR micro controllers
would end up with a modem in space (a Swedish team)  and being the subject
of a masters thesis!!

I'm stunned...

-- 
Robin Gilks zl3rob/g8ecj
Internet: g8ecj@gilks.org    http://www.gilks.org

Re: YAM modems at higher (shared) IRQ's

[Ray Wells]

On 12/03/11 03:26, Curt, WE7U wrote:
>
> I'm about done WRT further progress on the YAM driver, at least for now.
> I'm getting ancy to get something on the air, so have a 220 MHz mobile
> rig in to work with me today to redo the
> coax taps, then will hook it to one of: YAM / PK-232 / DSP-232. I can
> get one YAM going reliably on the motherboard serial port, then with the
> 4-port board talking to various TNC's I
> can do the other 1200 and 9600-baud links I want to do for now.
>
> As of last night I can get one of the YAM's configured every time on the
> motherboard's serial port, but never using the 9835/9845 cards. The
> second YAM board is being finicky in all cases but I don't know if it's
> the driver or the board.
>
> I tweaked the driver yesterday to better supply power to the board.
> During programming the PWR LED stays lit now instead of flashing, and
> that LED is always on nice and strong. Power is supplied via two
> handshake lines that need to be at opposite states to keep +12V/-12V
> supplied. One of those is used during programming and also controls PTT.
> Weird, but some people do anything to save a buck. I've seen worse!
>
> I may add a function to the driver for controlling the two handshakes so
> that they are always kept at opposite states. Right now it's all done
> with bit-twiddling of both lines on the spot, and you have to keep the
> opposite-states thing in mind while tweaking any of those spots.
>
> Also: I was wrong about the driver using UART loopback mode during
> operation. It only uses loopback mode to decide what sort of UART is out
> there, then switches back to normal operation. The trick they're doing
> in order to accomplish synchronous programming of the Xilinx: They set
> the data line (RTS in this case), then throw $0xFC into the transmit
> buffer which causes this bit pattern to be sent out on the CLOCK line:
>
> 1 1111 1100 0
>
> That first 1 is a start bit, then 8 bits of data, then a stop bit. This
> produces a nice clock pulse to program the data bit into the Xilinx
> with. Not a bad trick to use an asynchronous port to do synchronous
> programming of a part.
>
> Another thing I found out yesterday is that there's a v1.7 YAM and a
> v1.10 YAM. I have two v1.10b boards. They require different MCS firmware
> loads because Xilinx pins have been moved and the board layout has been
> changed. I don't know which firmware is in the Linux driver now. It
> would be nice to have that documented and the firmware added to the
> kernel so people would
> know to choose the proper one for their board. The driver appears to
> have the capability to use an alternate file, but there aren't any
> alternate files to be had in the kernel. I just found an MCS file for
> the v1.10 board, but it's just a single one, so they might have combined
> the 1200 and the 9600 baud circuits into one now. How they are chosen
> via software is something I have yet to figure out.
>
> Any pointers as to who to submit the patches to? Probably the
> kernel-hackers list? How to submit them? It might be a few more days or
> weeks before I get around to it though. I've tested the driver on 64-bit
> and 32-bit, but will do so again before I send any patches upstream.
>

Curt,

Have sent you some YAM files I've collected over the years. Have other 
documentation
in hard copy format including connections to various parts of the FPGA. 
I'm still
looking for an article on a modification to the YAM to help it cope with 
varying
DC voltage that might be applied to the input from the radio 
discriminator with DC
coupling. Another modification was to use a separate power supply to 
overcome some
comports supplying insufficient voltage - I had one that provides only 3.5V.

Ray vk2tv

Re: YAM modems at higher (shared) IRQ's

[Dave Platt]

On 03/09/2011 07:07 PM, Curt, WE7U wrote:
> On Wed, 9 Mar 2011, Curt, WE7U wrote:
> 
>> What I found out:  The 16550 interface that I was trying to get
>> running... ain't.  It's a 16550-compatible multi-port card, NOT a card
>> with 16550A's.
> 
>> Worse, I examined the 2-port cards I have:  They're also
>> 16550-compatibles (SYBA 2-port PCI cards).
> 
>> In my spare parts I found one PCI card with a real 16550A, a
>> single-port card.

I wonder... how much of the compatibility problems you're seeing,
have anything to do with the chip itself (16550 vs. "compatible")
and how much have to do with the external analog interfaces used
by the board vendors?

A lot of serial ports these days are only "barely RS-232",
and some don't even comply with the RS-232 spec.  RS-232 requires
both positive and negative voltage swings (minimum of +/-
3 volts if I recall correctly, with +/- 12 having been the
old "nominal" swing).  Modern serial ports may only swing
+5 and 0 (no negative swing at all), or may swing only
just past the +/- 3 volt limits.  The receiver thresholds on
such devices are often set at around 1.5 volts or so.

Furthermore, the amount of power which can be "robbed" from
the handshaking lines is often quite miniscule... just a
few milliamperes.

Since the YAM is intended to be port-powered, I suspect it
is going to be very prone to not work correctly when used
from these wimpy, under-voltaged-and-under-powered ports.
If the handshaking lines can't pull well above +5 while
providing enough juice to run the FPGA, the device probably
will not initialize properly.

Here's my guess:

-  If you have a serial port with a 1488 quad-line driver
   IC, it's likely to work, as these drivers are powered from
   +12/-12 rails and have plenty of current drive capacity.

-  If you have a serial port with a MAX232 or similar
   voltage-doubling driver, it may work, depending on the
   actual output voltage generated on the handshaking pins and
   the amount of current which can be drawn.  Voltage-doubler
   chips which have small on-chip capacitors may be less likely
   to have the necessary current-sourcing capacity, than those which
   use larger (e.g. 1-to-10 uF) off-chip caps.

-  If you have a serial port which simply provides "pseudo-RS-232"
   driver (inverts the TTL/CMOS logic, with no negative voltage
   swing) I suspect it's unlikely to work.

As I see just now that Ray has suggested, you may be able to
overcome the RS-232 voltage issues by using a separate (outboard)
power supply to run the YAM circuitry.  This might provide better
compatibility with a broad range of modern serial ports, which
are usually very register-compatible with 16550A UARTs but which
differ at the electrical level.

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

On Sat, 12 Mar 2011, Ray Wells wrote:

> Have sent you some YAM files I've collected over the years. Have other 
> documentation in hard copy format including connections to various parts of 
> the FPGA. I'm still looking for an article on a modification to the YAM to 
> help it cope with varying DC voltage that might be applied to the input from 
> the radio discriminator with DC coupling. Another modification was to use a 
> separate power supply to overcome some comports supplying insufficient 
> voltage.

Woohoo!  Got your other message, thanks!

I've been prowling around and found about three sites that have YAM info on them.  Found/downloaded the yam1_10.mcs file today which it says I need for these two boards (which are v1.10b).

I found a "MK1" YAM clone on one site which had a different layout and the site was written in a language I didn't know.  I saw mention (On that site I think) of a power mod for external power, but was not aware of any DC-coupling mod.  I'd be quite interested in both of those mods.

I don't know if I'll end up using a YAM much, or for long.  If not I can pass off what I've collected to the next guy with a better Linux driver and maybe some H/W mods to make them work better.

These are the YAM sites I know of:
http://www.jaffa.it/mirrors/guerrilla.net/reference/yam_9k6/yamdown.htm
http://gbppr.dyndns.org/guerrilla.net/reference/yam_9k6/yamdown.htm
http://sharon.esrac.ele.tue.nl/pub/packet/yam/features.htm
ftp://ha5ob.ham.hu/hamradio/modem/yammodem/download.htm

SMD version:
http://www.qsl.net/dg1scr/pr/yam/index_e.html

Clone board:
http://www.ampr.poznan.ws/users/sp3uqs/yam_mk1/index.html

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.

Re: YAM modems at higher (shared) IRQ's

[Curt, WE7U]

On Fri, 11 Mar 2011, Dave Platt wrote:

> I wonder... how much of the compatibility problems you're seeing,
> have anything to do with the chip itself (16550 vs. "compatible")
> and how much have to do with the external analog interfaces used
> by the board vendors?

I starting walking down that same path yesterday afternoon!

I figured out how they're doing the synchronous clocking, and it has nothing to do with a 16550.  It's just standard UART stuff.  The only "16550" stuff required is the particular registers at particular addresses, and control of a couple of handshake lines by bit-twiddling.


> A lot of serial ports these days are only "barely RS-232",
> and some don't even comply with the RS-232 spec.

Yep.  The boards with the 9835/9845's on them are doing +11.25 or higher, and -11.25 or lower on the swings.  Measured that last night.

I also measured the good ports and they are the same.  I found one handshake at a different state between the "good" and "bad" interfaces after configuration, then started in to the driver again and found that the two handshakes that were always supposed to be at opposite states (to provide power to the board) weren't being handled that way in the driver.

I haven't gone back to verify the current capability from either interface (spec says should supply 7mA per line at 12V or sink 7mA at -12V if I remember correctly), or that the power supply to the chip remains between 4.75 and 5.25V the entire time.  I need to do so yet.


> Since the YAM is intended to be port-powered, I suspect it
> is going to be very prone to not work correctly when used
> from these wimpy, under-voltaged-and-under-powered ports.
> If the handshaking lines can't pull well above +5 while
> providing enough juice to run the FPGA, the device probably
> will not initialize properly.

Yes, which is why I'd rather power it from my 20A Astron.  That ought to have enough ooomph!


> As I see just now that Ray has suggested, you may be able to
> overcome the RS-232 voltage issues by using a separate (outboard)
> power supply to run the YAM circuitry.  This might provide better
> compatibility with a broad range of modern serial ports, which
> are usually very register-compatible with 16550A UARTs but which
> differ at the electrical level.

Yep.  My thoughts too.  Since I need +12V all over the shack anyway to power darned-near anything, I might as well tap off that and make the YAM more reliable in the process.

Which reminds me:  If a vendor has a deal on a Saratoga powerpole distribution strip tomorrow at the hamfest I'll pick one up.  I already have one in the Jeep to distribute 12V.

-- 
Curt, WE7U.        http://www.eskimo.com/~archer
APRS Client Capabilities:  http://www.eskimo.com/~archer/aprs_capabilities.html

Re: YAM modems at higher (shared) IRQ's

[David Ranch]

Hey Curt,
> Any pointers as to who to submit the patches to?  Probably the 
> kernel-hackers list?  How to submit them?  It might be a few more days 
> or weeks before I get around to it though.  I've tested the driver on 
> 64-bit and 32-bit, but will do so again before I send any patches 
> upstream.
[slightly updated and resending to the linux-hams list as others  might 
find it helpful]


1. Get the newest available vanilla Linus kernel (today, that's 2.6.37)

2. Look at the MAINTAINERS.txt file and see who is the maintainer for 
the Yam driver.  I see:
-- 
YAM DRIVER FOR AX.25
M:      Jean-Paul Roubelat <jpr@f6fbb.org>
L:      linux-hams@vger.kernel.org
S:      Maintained
F:      drivers/net/hamradio/yam*
F:      include/linux/yam.h
-- 

3. Read this article in the source tree:

    Documentation/SubmittingDrivers

4. In an email to the YAM driver maintainer, you need to cite:
  a. reason for the patch
  b. sign off on the patch as yourself (just a one liner in the email 
before the diff with a real email address)
  c. include the "-up" diffs against the newest vanilla kernel
  d. diffs cannot have line wraps

5. The Yam maintainer should accept and submit the patch.  If you can't 
reach that maintainer, you should be able to submit the patch directly 
to the kernel-hackers list and someone else will commit for you assuming 
they pass muster (sane code, comments, etc.)


Here is the very simple patch I submitted which was also signed off by 
the USB serial driver maintainer
-- 

This patch is to add a US Interface, Inc. "Navigator" USB device.
Specifically, it's a HAM Radio USB sound modem that also
incorporates three pairs of unique FTDI serial ports.  The standard
Linux FTDI serial driver will only recognize the first two serial
ports of an unknown FDTI derived device and this patch adds in
recognition to these specific new IDs.

Signed-off-by: David A. Ranch <dranch@trinnet.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
drivers/usb/serial/ftdi_sio.c     |    3 +++
drivers/usb/serial/ftdi_sio_ids.h |    5 +++++
2 files changed, 8 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -162,6 +162,9 @@ static struct usb_device_id id_table_com
    { USB_DEVICE(FTDI_VID, FTDI_SCS_DEVICE_5_PID) },
    { USB_DEVICE(FTDI_VID, FTDI_SCS_DEVICE_6_PID) },
    { USB_DEVICE(FTDI_VID, FTDI_SCS_DEVICE_7_PID) },
+    { USB_DEVICE(FTDI_VID, FTDI_USINT_CAT_PID) },
+    { USB_DEVICE(FTDI_VID, FTDI_USINT_WKEY_PID) },
+    { USB_DEVICE(FTDI_VID, FTDI_USINT_RS232_PID) },
    { USB_DEVICE(FTDI_VID, FTDI_ACTZWAVE_PID) },
    { USB_DEVICE(FTDI_VID, FTDI_IRTRANS_PID) },
    { USB_DEVICE(FTDI_VID, FTDI_IPLUS_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -40,6 +40,11 @@

#define FTDI_NXTCAM_PID        0xABB8 /* NXTCam for Mindstorms NXT */

+/* US Interface Navigator (http://www.usinterface.com/) */
+#define FTDI_USINT_CAT_PID    0xb810    /* Navigator CAT and 2nd PTT 
lines */
+#define FTDI_USINT_WKEY_PID    0xb811    /* Navigator WKEY and FSK 
lines */
+#define FTDI_USINT_RS232_PID    0xb812    /* Navigator RS232 and CONFIG 
lines */
+
/* OOCDlink by Joern Kaipf <joernk@web.de>
 * 
(http://www.joernonline.de/dw/doku.php?id=start&idx=projects:oocdlink) */
#define FTDI_OOCDLINK_PID    0xbaf8    /* Amontec JTAGkey */