twelvetone12
Well-known member
Ok so we should be able to rule out the software 
Flow control should be working since it is one of the thing I had to bodge (cough cough) but I will double check with the scope to be sure. The adapter is the same I used for the "working" one, and FTDI chip, so at least on the software part it should be ok. I'm wondering if there is something maybe with the power supply and the tranceiver cannot generate the correct levels on the bus. I will see what the scope shows.
I have a small program that sends a frame full of "r"s. When I use the working adapter, I can see all the "r"s in the terminal (plus the rest of the binary data). When I do the reverse I just see random stuff.I don't see anything obviously wrong on the signal side. What kind of garbage are you getting from LT_IN_OUT when you send data from the USB2LT, and what are you using for a test case?
Ok I will bring out the scope and test this, I think I should be able to decode the frames by hand.I'd start testing by just writing a single ENQ frame to the UART (0x01 followed by 0x01 0x01 0x81 0x01 0x01 - the CRC doesn't have to be correct) and seeing if TashTalk sends out the correct data on LT_IN_OUT. If it does, then check whether it's something on the level-shifting side. If it doesn't, especially if you're running tashtalkd for testing, one thing I'm tempted to suggest is that flow control isn't working properly, maybe your USB-serial chip isn't reading CTS correctly, or the driver isn't using RTS/CTS flow control, or something like that?
Flow control should be working since it is one of the thing I had to bodge (cough cough) but I will double check with the scope to be sure. The adapter is the same I used for the "working" one, and FTDI chip, so at least on the software part it should be ok. I'm wondering if there is something maybe with the power supply and the tranceiver cannot generate the correct levels on the bus. I will see what the scope shows.