Listening for packets

[cosmicvoid]

I guess you are running under linux of some sort, and I've not done any programming in that OS. Here is what I do in my Windoze apps:

Open the COMn: port as a file type of stream, with at least a 1K rx buffer.

Start a thread whose purpose is to poll the rx buffer status. When the thread finds more than 0 characters waiting in the rx buffer, it reads them one by one and calls the parse function, with a byte as the argument. This way, the rx buffer gets emptied quickly, so there is no overflow.

The parse function is a state machine, which looks for the elements of a packet. Any byte which fails validation for the state is tossed and the state machine starts over at state 0. So, possibly 1 packet will be discarded until it syncs up to a packet boundary, then it should stay in sync and see all packets unless there is data corruption.

The best I can do is give you a sample in C or C++, if that would help.

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[starlon]

Well, I don't think this packet code is allowing bad packets through. I think it is something else, because there's little chance that bad packets are getting through this code. I wouldn't mind seeing the code, sure.

Yeah this code reads (peeks) bytes 1 by 1 usually, except when the program knows the length of the data to read. It's all in the code I pasted.

I did finally work out a way to wait for a response before sending another command. It was about 3 or 4 lines of code. The program assumes the next response packet matching the command is the one it's waiting for. The program resends commands a lot though. I need to find out why. Like every command gets resent. I don't know why it doesn't keep resending perpetually however. That's next to-do.

 

[cosmicvoid]

Well, I don't think this packet code is allowing bad packets through. I think it is something else, because there's little chance that bad packets are getting through this code. I wouldn't mind seeing the code, sure.

How then do you explain the fan packets with bogus RPM values?

Attached is a small section of my windows code, showing the monitor thread and parser state machine, in C++.

 

[starlon]

Well, if bad packets are getting through this code, Crystalfontz can improve on it, because it's their algorithm as far as I know. My guess is it's similar to the algorithm used in CC, as it's my guess CC conforms to the specifications layed out in these devices' documentations, which suggest to use this algorithm for packets. I'm certain packets aren't getting through not because I feel it's flawless by inspecting it, but because I feel it is a tried and true algorithm.

 

[cosmicvoid]

Well, if bad packets are getting through this code, Crystalfontz can improve on it, because it's their algorithm as far as I know.

I don't think the CFA code has a flaw, but you have translated C++ to python, and can you say for sure that your translation hasn't introduced any behaviorial differences or side effects? If not, then your code would work the same as WinTest does, but apparently it doesn't.

 

[starlon]

There's no difference between the two except two lines to check to see if the str object returned by peek is empty or not. The rest is exactly the same. I'm confident of that. It would likely not work at all if I failed to port that little bit of code. I have gone further and isolated the packets like I was wanting to avoid. I'm allowing it to run till it either prints the debug message indicating that something about the fan report packet wasn't right or it just crashes due to other non-related issues. So far it hasn't shown anything, but then again I could never get it to reproduce a bad fan packet anyways. I think it was just a race condition, which would be fixed with the change I made to isolate packets.

 

[starlon]

Well, I woke up and found bad fan packets got through even after I isolated the packets. I don't get it. I'll do more debugging. I'm sure the answer's simple. I wish these packets were more common.

Edit: Ok, found another case for a race condition. That's likely what happened lastnight.

 

[CF Tech]

I was wondering if the packet got corrupted after the CRC was checked. In C you can have wild pointers that whack stuff like that, but I assume in Python, that cannot happen?

 

[starlon]

It was a race condition. At first I had a single packet object that I would build upon and read from throughout the program. Well, that kept getting replaced every time this timer executed the packet code. I isolated each packet, but still referenced self.packet instead of the local variable packet in one place, and that allowed for the race condition to persist. Someone else noticed my mistake before I caught it. I've had the program running since yesterday listening for fan packets and it hasn't had a single bad packet, so I'm filing this one away.

 

[CF Tech]

Awesome, I am glad you found the solution to the corrupted fan packets