If you open the terminal tab thing in ProScan (can't remember the exact name and don't have my computer available to check) you can see the data coming from the scanner that ProScan parses into the scanner display. If you hold on a channel, it's easier to see.
Uniden Remote Head Project
- Thread starter MA-radio-guy
- Start date
Another way in ProScan is to log the scanner data to a file. Go to the Options -> General tab then check the option "Scanner Data To Scanner Data.txt File". That way you could count positions with a text editor. The STS data you want to look at.
I'm looking at the ProScan data.txt file now. Good idea, thanks.
I'm still trying to get my head around the data placement though. I'm not seeing what to use to parse out each field. They aren't prefixed or addressed or whatever. Are you guys just looking at the SDS data as it comes out plucking it out of the string at the position it is expected to be?
I guess I need to run a file for simple vs detail and compare but I thought that data changed position depending on the display mode. In past projects the data came out in packets with opcodes where I could look for op code 0xwhatever and then expect the next xNumber of chars were what I wanted to strip out and point to a variable.
Detailed on the left, simple on the right.
I guess it's the XML portion that provides any sort of usable index?
I'm still trying to get my head around the data placement though. I'm not seeing what to use to parse out each field. They aren't prefixed or addressed or whatever. Are you guys just looking at the SDS data as it comes out plucking it out of the string at the position it is expected to be?
I guess I need to run a file for simple vs detail and compare but I thought that data changed position depending on the display mode. In past projects the data came out in packets with opcodes where I could look for op code 0xwhatever and then expect the next xNumber of chars were what I wanted to strip out and point to a variable.
Detailed on the left, simple on the right.
I guess it's the XML portion that provides any sort of usable index?
Last edited:
I know but the various bits of info come out in different positions in the data stream emitted by the radio depending on what is changed on the display layout. How do I index into a certain portion of data when that data can't be relied upon to be in the same spot? I mean I guess it's pretty stable it seems but it changes drastically between detail and simple and I'm looking for an indication as to what display type is enabled so the display could see that and adjust accordingly.
Maybe I'm making it more complicated than it need be, as I tend to do. I suppose it's as simple as looking for the first comma after the binary looking data and flagging that as the index for Option 1 data field, continue along and the next is Option 2 data, etc...
Last edited:
You have to parse for keywords. In VB you'd use functions like INSTR to get the position of keywords like "System Name=" and quotes, and copy the text in between to the display object displaying the system line on-screen. Most languages have an equivalent function.
The "binary looking data" tells the virtual display to show large or regular lines. After that it data, attributes, data, attributes in a repeating pattern.
Each field is 30 characters in length. The attributes off hand I believe an asterisk is reverse back and fore colors and an underline is an underline.
Each field is 30 characters in length. The attributes off hand I believe an asterisk is reverse back and fore colors and an underline is an underline.
Correct. After the 2nd comma is the data for the 1st line so get all 30 positions. Skip one for the comma then read the next 30 positions for the 1st line attributes and so forth.
IC-R20
LoBand Nation
- Joined
- Nov 19, 2018
- Messages
- 512
Right on, it was just the next town over from me and only $40 bucks so I just jumped on it. The adapter is not too big of a deal since I would have to run a power adapter to it regardless to keep it on all the time.
Excellent. Thank you!
Is that referenced in the documentation somewhere? I looked but did't see it. But I see now comparing it line for line against the 0/1 top to bottom. I was initially reading left to right then down for each block and trying to attribute it that way somehow.
This link explains the STS command better than the last two links.
http://info.uniden.com/twiki/pub/Un...CDx36HP_RemoteCommand_Specification_V1_05.pdf
http://info.uniden.com/twiki/pub/UnidenMan4/SDS100FirmwareUpdate/SDS100_Protocol_Docs_V0_01.zip
Note the last two links states that the PSI command is better than the STS command. I don't know if it's better but I do know that any program that uses the PSI command has to be changed from a polling type to an event type of serial communications. I don't think that would work if using the Ethernet port or later decide to support the DMA(Non HP/SDS) models.
{edit}
Looking at the STS Command, the [the Lx_Mode] fields (what I called attributes) are not fixed length if all the characters in that line are normal. Another curve ball throwing out there is the [Lx_CHAR] fields can contain commas if they are displaying text tags.
Last edited:
Ah OK. Interesting they didn't add that info to the other manual.
Major hudle (for me anyway) #1 cleared.
Direct USB connectivity similar to the original poster. Now I'm just hoping to be able to parse out the data and also direct commands to the Nextion display.
Direct USB connectivity similar to the original poster. Now I'm just hoping to be able to parse out the data and also direct commands to the Nextion display.
I have the code to parse out the display lines working. I'm able to see the representation of the display live updating in the serial monitor. But, for whatever reason my code is only updating once every second. I swear it used to update faster but after adding in all the serial.prints for debugging it seemed to slow so something's blocking. But then again I'm trying to do this while out of State at a work convention so not a lot of time to debug, just happy that I have display lines in variables.
I understand more now how the display is represented. I thought it spit out each editable field but it doesn't. It's done line by line all the way across from top to bottom. I can't send STS commands out on each loop or it overruns the radio's buffer and causes it to wig out or reset or just ignore me so I set up a non blocking timed delay that spits it out every 200 ms. If I can get the timing issues resolved the next task will be to work on the Nextion display code and direct the parsed out display vars to the display fields and read back in the touch inputs. I'm hoping that the page function can be used to spin up different pages with different display fields in response to the simple or detail mode etc... It seems the Nextion can do quite a bit of processing on board so hopefully some of that can be offloaded but not sure yet.
I understand more now how the display is represented. I thought it spit out each editable field but it doesn't. It's done line by line all the way across from top to bottom. I can't send STS commands out on each loop or it overruns the radio's buffer and causes it to wig out or reset or just ignore me so I set up a non blocking timed delay that spits it out every 200 ms. If I can get the timing issues resolved the next task will be to work on the Nextion display code and direct the parsed out display vars to the display fields and read back in the touch inputs. I'm hoping that the page function can be used to spin up different pages with different display fields in response to the simple or detail mode etc... It seems the Nextion can do quite a bit of processing on board so hopefully some of that can be offloaded but not sure yet.
Attachments
Last edited:
The timing is kicking my a... I have been polling at 200-250 ms. It works smoothly in scan but the search fields are slow. Normally it's about 1 MHz a second but when polling it slows it down to about half. Sniffing Proscan I see it's about the same polling rate but that program is hitting it with everything at once, all commands in a string do it should theoretically be even worse.
I'm lost as to why this is happening. I tried direct poll and response based on a cleared buffer but that was way too fast for the radio.
I'm lost as to why this is happening. I tried direct poll and response based on a cleared buffer but that was way too fast for the radio.
Windows OS uses timeouts called ReadIntervalTimeout, ReadTotalTimeoutConstant, ReadTotalTimeoutMultiplier, WriteTotalTimeoutConstant, & WriteTotalTimeoutMultiplier.
Anything similar in your environment you can tweak?
{edit} Also see if the RX and TX buffer size can be adjusted.
Last edited:
I'll look. I'm doing this on a Teensy 3.6 so it's all really primitive.
I saw something like that returned in a window in the Serial Port Monitor program. I'll see if there's something there I can test for and time off of it. Thanks
Last edited:
The Yuengling is an essential tool...
