USB2LT TashTalk Usb to LocalTalk

[twelvetone12]

Ok so we should be able to rule out the software

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?

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'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?

Ok I will bring out the scope and test this, I think I should be able to decode the frames by hand.
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.

 

[twelvetone12]

I've been playing with sending small packets and it seems Only control packets make it though?
For example if I write 0x01 0x01 0x81 I get it on the other side of the cable:

01 01 81 49 10 00 FD

(This is the raw data coming out of the other TashTalk, hence the 00 FD at the end)

But it I write a small DDP packet I get this:

self.sender.send_frame(bytes.fromhex("FF 01 01 00 06 02 02 01 FF"))

On the other side:

FF 01 84 CB DB 00 FD FF - 01 84 CB DB 00 FD FF 01 ........ ........
84 CB DB 00 FD FF 01 84 - CB DB 00 FD FF 01 84 CB ........ ........
DB 00 FD FF 01 84 CB DB - 00 FD FF 01 84 CB DB 00 ........ ........
FD FF 01 84 CB DB 00 FD - FF 01 84 CB DB 00 FD FF ........ ........
01 84 CB DB 00 FD FF 01 - 84 CB DB 00 FD FF 01 84 ........ ........
CB DB 00 FD FF 01 84 CB - DB 00 FD FF 01 84 CB DB ........ ........
00 FD FF 01 84 CB DB 00 - FD FF 01 84 CB DB 00 FD ........ ........
FF 01 84 CB DB 00 FD FF - 01 84 CB DB 00 FD FF 01 ........ ........
84 CB DB 00 FD FF 01 84 - CB DB 00 FD FF 01 84 CB ........ ........
DB 00 FD FF 01 84 CB DB - 00 FD FF 01 84 CB DB 00 ........ ........
FD FF 01 84 CB DB 00 FD - FF 01 84 CB DB 00 FD FF ........ ........
01 84 CB DB 00 FD FF 01 - 84 CB DB 00 FD FF 01 84 ........ ........
CB DB 00 FD FF 01 84 CB - DB 00 FD FF 01 84 CB DB ........ ........
00 FD FF 01 84 CB DB 00 - FD FF 01 84 CB DB 00 FD ........ ........
FF 01 84 CB DB 00 FD .......

It only sends RTS packets?

But if I swap serial ports (using the known working adapter to transmit, with TT 1.0), I get RTS + data:

FF 01 84 CB DB 00 FD FF - 01 01 00 FF 06 02 02 01 ........ ........
FF 4A B2 00 FD .J...

Basically the "garbage" I was seeing was not garbage at all, only RTS packets. The data packets seem never to make it out.
Could this be a CTS problem? It does seem the same even if I disable flow control.

 

[twelvetone12]

I did a bit more investigation, and it seems the PIC always ties CTS low? I never see the pin moving. When I send some data, the PIC always sends the RTS packets as above but seems to ignore all incoming data.

 

[tashtari]

That's odd, but I have a theory...

Are you setting the node ID bitmap on the receiving TashTalk? If not, then it's possible that the receiving TashTalk (when it's the USB2LT) has the bit set for the broadcast address 0xFF. If it does, when it sees the RTS frame that precedes a broadcast, it will respond with a CTS frame, which will make the sending TashTalk think the line is in use and back off and retry, which could account for all the RTS frames you're seeing. Before you send the frame, try sending an 0x02 byte followed by 32 0x00 bytes to the receiving TashTalk, that should make sure the node ID bitmap is set to all zeroes. If I'm right, that will solve it.

 

[twelvetone12]

Ok I tried this and I'm scratching my head a bit.
I'm using your python program which I modified just to send my packet. I open two instances, one writes the DDP packet (node 31) and one just reads it (node 32). I'm using the function to calculate and send the 0x02 + node ids. I make it very verbose (-vvv) so I get all the messages and packets in/out.


If I set TT 1.0 as 31 and write a packet to TT 2.0 @32, I see RTS, CTS, and my packet
If I set TT 2.0 as 31 and write to 1.0 @32, I see RTS, CTS over and over. The packet never seems to make it out in the serial port.

The packet is the same as above with the changed addresses:

self.sender.send_frame(bytes.fromhex("20 1F 01 00 06 02 02 01 FF"))

 

[tashtari]

If I set TT 2.0 as 31 and write to 1.0 @32, I see RTS, CTS over and over. The packet never seems to make it out in the serial port.

Hmm. This is what I'd expect to happen in this case:

1. TT 2.0 sends an RTS frame
2. TT 1.0 receives the RTS frame and echoes it to its UART
3. TT 1.0 responds with a CTS frame (which it does not echo to its UART)
4. TT 2.0 receives the CTS frame and echoes it to its UART
5. TT 2.0 responds with the data frame (which it does not echo to its UART)
6. TT 1.0 receives the data frame and echoes it to its UART.

Can you check that you're seeing a correctly-formed CTS frame come from TT 2.0's UART? That way we know we're getting as far as step 4, at least. If we're getting to step 4 but not to step 5, something might be wrong with the PIC or the firmware...

Also, just to be on the safe side, can you add a call to known_state() before you set up the ID bitmaps, just to rule out the possibility that some junk data or noise isn't getting TashTalk into a bad state so it doesn't set up the ID bitmap properly?

 

[twelvetone12]

This is the complete log of one transaction. Sorry it is a bit long and confusing
This is the transmitter side, TT 2.0 with USB2LT, set as node 31 sending to node 32. I highlighted the frame being sent to TT:

$ python3 tashtalkd -d /dev/ttyUSB1 -vvv
[DEBUG] return to known state sent to TashTalk
[DEBUG] ID bitmap sent to TashTalk: (empty)
[DEBUG] return to known state sent to TashTalk
[DEBUG] ID bitmap sent to TashTalk: 0x1f
[DEBUG] frame sent to TashTalk:
000000 20 1F 01 00 06 02 02 01 FF 37 92 ........7.
[DEBUG] read 28 bytes from TashTalk
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] read 56 bytes from TashTalk
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] read 35 bytes from TashTalk
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame

And this is the receiving side, TT 1.0 with an FTDI converter:

$ python3 tashtalkd -d /dev/ttyUSB0 -vvv
[DEBUG] return to known state sent to TashTalk
[DEBUG] ID bitmap sent to TashTalk: (empty)
[DEBUG] return to known state sent to TashTalk
[DEBUG] ID bitmap sent to TashTalk: 0x20
[DEBUG] read 21 bytes from TashTalk
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] read 56 bytes from TashTalk
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] read 42 bytes from TashTalk
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame
[DEBUG] not retransmitting RTS/CTS frame

So it seems it gets to 4, but for some reason the data frame never shows up?

I also have the scope hooked to the TT 2.0 LT output, it is not really easy to follow but my data frame never seems to get there. Even if I try a bigger frame I never see it on the scope.

As a reference, this is what happens if I swap TTs:
TT 1.0 sending the same frame to 2.0:

$ python3 tashtalkd -d /dev/ttyUSB0 -vvv
[DEBUG] return to known state sent to TashTalk
[DEBUG] ID bitmap sent to TashTalk: (empty)
[DEBUG] return to known state sent to TashTalk
[DEBUG] ID bitmap sent to TashTalk: 0x1f
[DEBUG] frame sent to TashTalk:
000000 20 1F 01 00 06 02 02 01 FF 37 92 ........7.
[DEBUG] read 7 bytes from TashTalk
[DEBUG] TashTalk received good frame:
000000 1F 20 85 08 F9 . ...

And this is what I read on TT 2.0:

$ python3 tashtalkd -d /dev/ttyUSB1 -vvv
[DEBUG] return to known state sent to TashTalk
[DEBUG] ID bitmap sent to TashTalk: (empty)
[DEBUG] return to known state sent to TashTalk
[DEBUG] ID bitmap sent to TashTalk: 0x20
[DEBUG] read 21 bytes from TashTalk
[DEBUG] TashTalk received good frame:
000000 20 1F 84 82 11 ....
[DEBUG] TashTalk received good frame:
000000 20 1F 01 00 06 02 02 01 FF 37 92 ........7.
[DEBUG] not retransmitting RTS/CTS frame

I highlighted the frame. Here I see all the steps in the list!

 

[tashtari]

I am really struggling to explain what's going on here. The only thing that sticks out to me is the fact that in the first case, there are apparently 17 attempts by the USB2LT to send the RTS frame. That's definitely not normal, there should be 32 and I'm wondering what's happening to the other 15...

Can you try and capture a scope trace of everything that happens on the LocalTalk/PhoneNet line from when you start the transmitter? It should fit into 50 ms, probably less. Maybe something will stick out as being wrong.

Meanwhile, I'll try and reproduce this locally as soon as I have a chance, with TashTalk 1.0 and 2.0 PICs...

Very strange.

 

[twelvetone12]

Here you go! Sorry for potato quality.
Blue is one of the differential lines on the RS422, Yellow is the LocalTalk D/RE on the TT, purple is the LocalTalk IO pin of TT.


This should be one packet and it's response, at 100uS/div


This is the zoomed out one at 1mS/div

And this is the whole transation. It seems in fact that there are always 17 attempts.
Let me know if I can make more screens!

EDIT: I ran 10 packets, and every time it seems the RTS is sent 17 times.
BTW here is reversed setup (working):

 

[tashtari]

Thanks for getting the traces. Nothing looks out of place (except the 17 attempts)... I'll try and get a test environment set up and see if I can duplicate it here.

 

[twelvetone12]

Thank you for helping me on this!

 

[tashtari]

Well, I just got things set up for testing and tried your test case, and of course everything worked perfectly... bleah. Of course, some parts of it are inevitably going to be different (I don't have a USB2LT, mainly) and it's hard to know which ones are significant. I guess the next step is, can you send me a nonworking USB2LT so I can reproduce locally? I guess that sort of raises the question, are all your USB2LTs doing the same thing, or is it just the one?

 

[twelvetone12]

Sure! I can send it to you. For the moment I built only this one, I will try to make another one and see. There are a couple things I want to verify as I've been scratching my head all day

* Programming: I programmed 2.0 with my PicKit 3, it works for 1.0 so I assume there are no caveats here? no special settings (I programmed a 1.0 this morning and it works)
* Maybe I damaged the PIC: I tied CTS to RTS on the FTDI chip, which is high, so maybe I killed the PIC? Which is weird, since I did ugly stuff to PICs in the past and I never killed one.

If all this fails, I can send it to you, just keep in mind that there is an ugly bodge and it is quite fragile so you will probably need to solder a cable on the SMD components.

 

[tashtari]

* Programming: I programmed 2.0 with my PicKit 3, it works for 1.0 so I assume there are no caveats here? no special settings (I programmed a 1.0 this morning and it works)
* Maybe I damaged the PIC: I tied CTS to RTS on the FTDI chip, which is high, so maybe I killed the PIC? Which is weird, since I did ugly stuff to PICs in the past and I never killed one.

Programming with the PICkit 3 should be fine, no special settings needed. I guess it's possible you fried something in the PIC but it seems unlikely. (I've fried a PIC exactly once in all the time I've been using them and I was doing something really stupid at the time...)

If all this fails, I can send it to you, just keep in mind that there is an ugly bodge and it is quite fragile so you will probably need to solder a cable on the SMD components.

Hmm, that could be a bit of a problem, I'm not very good at SMD soldering... let's try the other stuff first.

Another thought, actually - this shouldn't matter, but we're grasping at straws, so - can you try programming the PIC with the latest firmware (v2.1.0)? Like I said, it shouldn't make a difference, but it's one less variable...

 

[twelvetone12]

2.1 should be the version I used yesterday, but I will double check just to be sure.

 

[twelvetone12]

Ok I mounted a second one, I made sure all the wrong connections were fixed before power, and I get the same result.

If I set the node bitmap, I see 17 RTS -> CTS
If I set the bitmap to 0 on the receiver, I get 32 RTS and no response (which I right I think?)

I really can't put my finger on what's going on, because if I see the CTS on the console I imagine TT has correctly received it no?

 

[tashtari]

If I set the node bitmap, I see 17 RTS -> CTS
If I set the bitmap to 0 on the receiver, I get 32 RTS and no response (which I right I think?)

That is so weird. I really don't know how to explain it. It certainly sounds like a firmware bug of some kind, but I've no idea where it is...

if I see the CTS on the console I imagine TT has correctly received it no?

That's exactly what's confusing me - if it echoes a properly formed CTS, it's received it correctly, so why isn't it responding with the data frame?

 

[twelvetone12]

Could it be because I have the two tranceivers? What could inhibit TT from sending data?
In would imagine the serial part with the PC works, because it needs to receive my packet to send RTS and wait for CTS right? Does it do any manipulation of the incoming packet? I'm trying to narrow down what could make it upset... I could also modify a board to use TT 1.0 and see what happens there.
PS the RPi hat should be in the mail today! Is it for TT 1 or 2?

 

[twelvetone12]

The RPi hat finally made it here! So I immediately got to misuse it:



I lifted the LT io and LTEN pins, and used the transceiver there. Guess what? It works. So I think there is something with the two transceiver setup that does not work. My guess is that something happens with the shared io pin? I can't really imagine what tho...

 

[tashtari]

Could it be because I have the two tranceivers?

My early testing (with TashTalk 1.0) involved a setup similar to yours, with two SN65HVD08s, but it occurs to me that I don't think I've tested TashTalk 2.x with a two-transceiver setup. I don't know why it'd cause a problem, but it's something I ought to test, just in case. I'll see about doing that hopefully sometime today.

Is it for TT 1 or 2?

The hat is set up for the pinout of TashTalk 2.x, the PIC included with the kit has TashTalk 2.1 on it.