No suggestions, it's all compatible because it's all custom. The arduino is like a post office that gathers the stream of data from the radio and then parses it to bins with addresses. The data bins are stacked in logical order and sent out to the display where it parses them out by their address and displays them as designed in the locations set forth in the graphical hmi editor.
There are multiple ways to do it and some are better depending on the display capabilities or the amount of complexity desired.
Most of this could have been simplified had uniden kept the display line data format consistent. The 100 is not the same exactly as the 200. Some places blank data is truncated, some it's padded, sometimes commas are ignored, some not.
I tried simple comma parsing at first. It was fast and accurate right up until someone put a comma in a name field then all hell broke loose. So that didn't work. I then used data field size parsing. However data field sizes can change in certain circumstances so you have to account for that.
Not to sound flippant but until you really really have a total grasp on the data format you will run into issues. I say that because you won't be able to logically plan or anticipate what is needed and decide what can be handled by the processor or the display best.
My suggestion is to add serial debug print statements to my code and just sit and watch it. Use a good terminal program and see how it behaves. Once you see the portions that relate to fields you see on the screen then you start to understand or at least get a plan going of how to tackle the display code, that is, if you understand how the display handles data and what it can and can't do.
Be mindful of display quirks, buffer overruns, etc...
You need to likely try to load balance by parsing the data as much as possible before sending to the display. Remember, they are running i2c or some other fast bus inside the radio. You are constrained to noisy serial that's far slower and threading through multiple uarts with extra processors, interrupts, memory systems, touch sensors and other crap hanging off it.
There are multiple ways to do it and some are better depending on the display capabilities or the amount of complexity desired.
Most of this could have been simplified had uniden kept the display line data format consistent. The 100 is not the same exactly as the 200. Some places blank data is truncated, some it's padded, sometimes commas are ignored, some not.
I tried simple comma parsing at first. It was fast and accurate right up until someone put a comma in a name field then all hell broke loose. So that didn't work. I then used data field size parsing. However data field sizes can change in certain circumstances so you have to account for that.
Not to sound flippant but until you really really have a total grasp on the data format you will run into issues. I say that because you won't be able to logically plan or anticipate what is needed and decide what can be handled by the processor or the display best.
My suggestion is to add serial debug print statements to my code and just sit and watch it. Use a good terminal program and see how it behaves. Once you see the portions that relate to fields you see on the screen then you start to understand or at least get a plan going of how to tackle the display code, that is, if you understand how the display handles data and what it can and can't do.
Be mindful of display quirks, buffer overruns, etc...
You need to likely try to load balance by parsing the data as much as possible before sending to the display. Remember, they are running i2c or some other fast bus inside the radio. You are constrained to noisy serial that's far slower and threading through multiple uarts with extra processors, interrupts, memory systems, touch sensors and other crap hanging off it.
