LOL at the 'b' yea python 3 runs everyting as bytes. I'm sure .decode() is your new buddy by now.
What's your serial routine look like? Are you doing a general vanilla EOL or some non blocking constant buffer thing? One thing that surprised me is the radio can do simultaneous ports as in like Proscan running off ethernet and also our stuff off USB serial and seems to serve out separate data. I didn't expect it to be that advanced. It's very fast as well. I kept putting in micro sleeps to try to stabilze some data but ended up finding that running ballz out is where it's happy.
As for commas, look into modulo parsing at 30 wide. They ****ed up the code bad and that's not the only place. You can't get away from it and a simple comma slice won't ever do so abandon that now. Seriously, just forget about it. Also, check out what happens at the end of the system/dept/option fields at times. They forget to pad with 0x20 and just say the hell with it and give up at 26 chars.
I parse at modulo 30 which sanitizes it of all comma separators (after stripping the STS, 0000101010.... etc... display size attriburte data) to get a clean base 0 start at the display data then sub parse using a python ZIP function to parallel parse the display fields against a predefined field size list then do a frame buffer write in sync. You are runing on terminal which is a wholly different animal and live and immdiate so maybe the finer details are irrelevant. I'm thinking as I'm typing I can almost see how that would be advantageous as you could taylor outputs based on print routines as opposed to having to set and stage everything perfectly for each frame buffer write and refresh. You aren't dealing with touch inputs either so...
As for the USB device that's tricky. There seems to be something Windows does the rest don't and it's as if the radios flag a counter. No matter what windows does the radio is happy and just plays along. When I established comms using the PJRC Teency and the Pi the radio seemed to keep track of failed comms. 4 or more harsh USB pulls and it stopped communicating, needing a power reset to clear whatever its going on. Also, in my initial code I looked for the device ID of the Uniden radio. It's something XXX.1965 I think. I have to look in old code to find it but you can search for the commands to do a peripherial device ID search and it will show it. I'm going to have to revisit this issue myself and see what can be done more about it. I just did a complete program halt and respawn to get around it as a cyclic check waiting for a device to present but that has its own issues.
The way they presented the data from these things makes all this far more complicated than it should be. The color control is just outright silly. I mean it's 2 attributes per field and there are 50 fields just for the detailed layouts. I get there's no way around that but damn, they make us go find, open and parse and a file that looks like it was written by the IRS just to figure it out. I'm working through that now trying to parse the config file and point the hex color data to those variables. If they had an STS data output command that appended color data to the end of each field and each field delimited with something other than a user selectable char life would be divine. I can see how this is not so much a deal for high level envoronments like Windows apps where you can control text attributes to the single char it's maybe not so bad, but for us grovelling around here in the microcontroller SBC specialized library welfare class resources are sparse.
I can hear Bob with Proscan snickering from here...
Last edited:
