Does it work on the 996P2/325P2 as well?
Uniden Remote Head Project
- Thread starter MA-radio-guy
- Start date
No, not as it is.
What's the parts list look like?
Teensy 3.6, some sort of USB breakout board and a Nextion board?
Teensy 3.6, some sort of USB breakout board and a Nextion board?
I'm using the Nextion of course and then a Teensy 3.6. The breakout level converter board ended up not being necessary. I initially though the Nextion lines were 5v but they are 3.3 so went direct to the Teensy.
Basically all it consists of is the display, Teensy and whatever cabling you want to use. I cut up and old USB extension cable which gave me USB a plug and also a USB socket to plug a cable into and then into whatever radio.
I am trying to find someone who would be willing to modify two of my RH-96s to work with two of my BCD996P2s. ANYONE INTERESTED? I'm willing to pay you and perhaps even negotiate offering as payment one of my several RH-96s.
eorange
♦RF Enabled Member♦
Are you powering the Nextion directly from the Teensy? I didn't think it could supply the required current.
No a dedicated USB for power only powers both then a separate USB goes to the radio for data.
Apologies for the delays. I decided to go back and redo much of the data handling. Initially it used the strtok function to scan for commas and throw the data in between into variables that went out to display fields or were used for control. This was fine and was fast but I quickly realized it all went bad if a comma was introduced into one of the text fields. I didn't realize that was even possible but I tested it and it is. There's no easy way around that that I can think of. How would I tell it to skip commas in between just those areas. I know it's possible but is beyond my search engine based coding self education 
.
I am now using the same fucntion that grabs the initial total array of data to count the total number of chars, the total commas (in case needed) and the size of the display attributes field. I am adding the initial STS header and the attributes field then using that as the initial offset pointer into the start of the actual display data since the field can vary from 10 to 20 chars in length which wrecks any static pointing method. I'm just using for loops to extract them from there on out. It's tedious but hopfully I can use some variables in the loops based off the counter from the new start pont to help automate it a bit. The hope is also that the attributes field can be used to dynamically adjust the line widths which is why it exists (no separate page for each possible screen combo). Everything is a tradeoff, display processing for bandwith, simplicity for flexibility, etc...
The advantage over the other method in addition to the comma problem is the that each individual customizable field is independent and can later be edited for font or color or what not (provided the display coding handles it) later on instead of one line across only.
As you can see, if still reading, is that you end up basically writing a large portion of the UI just to display and interact with it, essentially building a totally new control head vs. some dumb terminal, unfortunately (I'm sure Bob is lauging at me now).
Also, the Nextion screens are nice but 1- they are expensive, 2- they have limited memory (especially if doing independent fields), 3- they have the huge carrier PC board attached, 4-seem to be power hungery, 5-other show stopper issues that would need resolved.
I have ordered and have in hand an Adafruit RA8875 display driver and separate resistive touch controller board. I ordered the corresponding 5" and 4.3" touch screens that go with them. This is another whole level of learning (more time and delay and gray hair) but if they work out decently (if I'm not too dumb) then that means we have the ability to do a direct drop in of display with relatively small support boards into existing devices (ie: Garmin, TomTom, control panel ripped off a printer, whatever you can stuff it into). Also, it's SPI instead of serial so should be faster. There's a butt load of old but nice GPSs on the used market for less than $20. I'm placing a lot of hope on being able to figure it all out and make these new parts work but I think the gamble is worth it.
I still plan on finishing the Nextion code and have the menu reverse text indication working for that now which makes it at least 80% usable (detail, simple, menu, closecall).
One thing is for sure, you'll never hear me complain about product release dates!
.I am now using the same fucntion that grabs the initial total array of data to count the total number of chars, the total commas (in case needed) and the size of the display attributes field. I am adding the initial STS header and the attributes field then using that as the initial offset pointer into the start of the actual display data since the field can vary from 10 to 20 chars in length which wrecks any static pointing method. I'm just using for loops to extract them from there on out. It's tedious but hopfully I can use some variables in the loops based off the counter from the new start pont to help automate it a bit. The hope is also that the attributes field can be used to dynamically adjust the line widths which is why it exists (no separate page for each possible screen combo). Everything is a tradeoff, display processing for bandwith, simplicity for flexibility, etc...
The advantage over the other method in addition to the comma problem is the that each individual customizable field is independent and can later be edited for font or color or what not (provided the display coding handles it) later on instead of one line across only.
As you can see, if still reading, is that you end up basically writing a large portion of the UI just to display and interact with it, essentially building a totally new control head vs. some dumb terminal, unfortunately (I'm sure Bob is lauging at me now).
Also, the Nextion screens are nice but 1- they are expensive, 2- they have limited memory (especially if doing independent fields), 3- they have the huge carrier PC board attached, 4-seem to be power hungery, 5-other show stopper issues that would need resolved.
I have ordered and have in hand an Adafruit RA8875 display driver and separate resistive touch controller board. I ordered the corresponding 5" and 4.3" touch screens that go with them. This is another whole level of learning (more time and delay and gray hair) but if they work out decently (if I'm not too dumb) then that means we have the ability to do a direct drop in of display with relatively small support boards into existing devices (ie: Garmin, TomTom, control panel ripped off a printer, whatever you can stuff it into). Also, it's SPI instead of serial so should be faster. There's a butt load of old but nice GPSs on the used market for less than $20. I'm placing a lot of hope on being able to figure it all out and make these new parts work but I think the gamble is worth it.
I still plan on finishing the Nextion code and have the menu reverse text indication working for that now which makes it at least 80% usable (detail, simple, menu, closecall).
One thing is for sure, you'll never hear me complain about product release dates!
Last edited:
eorange
♦RF Enabled Member♦
You encountered two key principles:
1. Never trust your input data.
2. UI development takes a lot of work.
I had a similar issue with my Pi ads-b scanner...for whatever reason, I would not get the expected amount of data, also separated by commas. This happened about once every couple thousand input records. I had to test every row for completeness and if something was missing, I just threw the whole row away. The input stream was so frequent (about 10,000 rows per minute) that no significant data was lost.
Your problem is more challenging to solve. Having un-escaped or unencoded commas in data which is separated by commas is poor protocol design.
One advantage of using a non-intelligent display is if you have a good supporting library (i.e. pygame), then just about all memory and other difficulties are abstracted away from you, the developer. The Nextion makes it easy to get a nice-looking display up and running quickly. To be fair, those displays are targeting the HMI market where controls and data are generally kept to a minimum for simplicity on the shop floor (for example).
1. Never trust your input data.
2. UI development takes a lot of work.
I had a similar issue with my Pi ads-b scanner...for whatever reason, I would not get the expected amount of data, also separated by commas. This happened about once every couple thousand input records. I had to test every row for completeness and if something was missing, I just threw the whole row away. The input stream was so frequent (about 10,000 rows per minute) that no significant data was lost.
Your problem is more challenging to solve. Having un-escaped or unencoded commas in data which is separated by commas is poor protocol design.
One advantage of using a non-intelligent display is if you have a good supporting library (i.e. pygame), then just about all memory and other difficulties are abstracted away from you, the developer. The Nextion makes it easy to get a nice-looking display up and running quickly. To be fair, those displays are targeting the HMI market where controls and data are generally kept to a minimum for simplicity on the shop floor (for example).
Raw display and driver. I'm having issues with the Sumotoy Ra8875 library. The one shown is the basic Adafruit and works fine. The Sumotoy has wavy lines. I read it could be SPI speed related and I tried dropping the speed but it doesn't seem to matter.
I got it working fine with the 4.3" but it doesn't like the 5". The Adfruit library works fine with both. I see there is a way to create layouts using the guislice HMI IDE. I'm looking into that now but I have some example stuff running along side the Uniden code so at least the display and the Uniden code work together so far.
Installed into the Garmin Nuvi.
Fold that RA8875 board back and attched to the display with 3m double sticky tape then mount the Teensy 3.6 board. From what I can see so far there is room to keep the lithium battery pack and then work on USB exit points. The existing port is in the back straight out and miniUSB which would not be ideal since it would require mini USB to micro USB which is odd so I think making USB A port openings or just running cables out that mini USB hole to female/male USB terminations would probably be the best.
So, maybe add a charge controller for the battery and it would run for however long on battery power.
EDIT: After the pic I printed some of the display variables from the Uniden to the fields left of the clock and could see them update there where the date was. (volume indication).
Installed into the Garmin Nuvi.
Fold that RA8875 board back and attched to the display with 3m double sticky tape then mount the Teensy 3.6 board. From what I can see so far there is room to keep the lithium battery pack and then work on USB exit points. The existing port is in the back straight out and miniUSB which would not be ideal since it would require mini USB to micro USB which is odd so I think making USB A port openings or just running cables out that mini USB hole to female/male USB terminations would probably be the best.
So, maybe add a charge controller for the battery and it would run for however long on battery power.
EDIT: After the pic I printed some of the display variables from the Uniden to the fields left of the clock and could see them update there where the date was. (volume indication).
Last edited:
Oooh SPI is so much nicer. I'm down to 150 ms data polling with no interruption to radio activity while live updating the channel name to the display. The font is crud but we'll work on that later. It looks much nicer in real life, far more contrast with a darker black background.
Last edited:
If anyone is interested please post or send ideas for a 4.3" layout.
Is there enough room for keypad and display info?
If not, how should we control this?
One button to get to a keypad screen?
I need some ideas.
Is there enough room for keypad and display info?
If not, how should we control this?
One button to get to a keypad screen?
I need some ideas.
eorange
♦RF Enabled Member♦
1. Do you need the remote head for Control + Display, or Display only? If designed for mobile...wouldn't the radio be nearby for button pushing anyway?
2. For the Display...is it necessary to exactly duplicate the scanner's display? Or can you minimize the info on the screen? If the use case is mobile, then less can be more when you're driving and you want to glance over to see what you're hearing. Maybe just display the System, TGID, Alpha Tag, RID, NAC. Think how large the fonts could be for easy viewing.
3. If Control + Display is desired, then consider one button on the Display that switches to Control mode for button pushing. Now you have more room to display buttons, and then you can flip back to Display mode when done, or it flips back automatically if no button is pushed after [n] seconds.
Again, think mobile design and not "I must do what Uniden did".
2. For the Display...is it necessary to exactly duplicate the scanner's display? Or can you minimize the info on the screen? If the use case is mobile, then less can be more when you're driving and you want to glance over to see what you're hearing. Maybe just display the System, TGID, Alpha Tag, RID, NAC. Think how large the fonts could be for easy viewing.
3. If Control + Display is desired, then consider one button on the Display that switches to Control mode for button pushing. Now you have more room to display buttons, and then you can flip back to Display mode when done, or it flips back automatically if no button is pushed after [n] seconds.
Again, think mobile design and not "I must do what Uniden did".
I agree with @eorange.
For me, a touch screen remote head display would ideally have the following KISS features:
1. Cleaner, simplified display for legibility with larger TGID, Alpha Tag, RID, NAC
2. Single row of large buttons below display for System, Dept, Chan hold, record/replay, Vol up/down/mute, then a single menu button to pull up a full keypad with menu & function buttons, and up/down/enter navigation buttons to control quick key and full menu features.
For me, a touch screen remote head display would ideally have the following KISS features:
1. Cleaner, simplified display for legibility with larger TGID, Alpha Tag, RID, NAC
2. Single row of large buttons below display for System, Dept, Chan hold, record/replay, Vol up/down/mute, then a single menu button to pull up a full keypad with menu & function buttons, and up/down/enter navigation buttons to control quick key and full menu features.
All good points but there would be tradeoffs. All that fine detail like NAC, WACN, SITE, RFSS etc... would need to be removed. Also, it would likely require an adherence to a certain screen layout. In other words, the SDS display can be heavily modified by the user to display data in various configurable locations. The main SYS,DEPT,CHAN fields would be displayed of course but the mobile display would have to refer to a known field and the user would have to adapt their radio settings to point data they want displayed to that location.
Since my intended use for a remote head would be in a vehicle attached to my SDS100, mostly a display with simple functions such as channel/dept/system hold would be good. It would be really nice if I could tap on the system being displayed to hold it. Same for Dept and Channel.
My plan would be to have the scanner close by so I could access the scroll knob for volume and channel selection.
Others may need more complex functionality, but bgav notes, simple would be better.
My plan would be to have the scanner close by so I could access the scroll knob for volume and channel selection.
Others may need more complex functionality, but bgav notes, simple would be better.
eorange
♦RF Enabled Member♦
Are you saying that if you remove a field from the SDS display, then that field won't be available in the data stream? If so...boooo Uniden!
No, trying to figure out how to explain in text. If you look at the user manual you see the diagram of the simple and detail display mode screens. As you can see the items vary; no Option_5 or Option_6 in detail mode etc...and no Option A_1 through B_5 in simple mode. All that data is available depending on which screen mode you select. However, if you do not want to see all those fields on a remote control head a decision is needed as to what of those fields the head picks out of the stream and displays.
The assumption is for either mode you would have at the minimum of course:
SYSTEM NAME
DEPT NAME
CHANNEL NAME
Likely system Option fields below those.
However, in simple mode it's possible to display double length names due to it using two lines of text in lieu of the smaller fields the detailed mode uses.
If you want some of the Option fields, which ones? A couple could be selected depending on real estate (say, Option_7 and Option_8). But to choose what is displayed there would depend on the user editing those fields in the radio display editor menu. The only other option would be to completely emulate the user interface and let the display allow the user to choose what to pick from the data stream. That is way beyond the scope of what's going on here.
It seems the consensus so far is simple is better (HomePatrol) type layout with touch hold over SYSTEM NAME, DEPT NAME, CHANNEL NAME fields. I'll work in that direction. Remember, though that eliminates MENU options such as search and what not unless an interface for that is resolved simply but for simple throw on the dash to see what's happening and hold on a channel it would be fine.
The assumption is for either mode you would have at the minimum of course:
SYSTEM NAME
DEPT NAME
CHANNEL NAME
Likely system Option fields below those.
However, in simple mode it's possible to display double length names due to it using two lines of text in lieu of the smaller fields the detailed mode uses.
If you want some of the Option fields, which ones? A couple could be selected depending on real estate (say, Option_7 and Option_8). But to choose what is displayed there would depend on the user editing those fields in the radio display editor menu. The only other option would be to completely emulate the user interface and let the display allow the user to choose what to pick from the data stream. That is way beyond the scope of what's going on here.
It seems the consensus so far is simple is better (HomePatrol) type layout with touch hold over SYSTEM NAME, DEPT NAME, CHANNEL NAME fields. I'll work in that direction. Remember, though that eliminates MENU options such as search and what not unless an interface for that is resolved simply but for simple throw on the dash to see what's happening and hold on a channel it would be fine.
Last edited:
eorange
♦RF Enabled Member♦
Ok, I see. So try not to overthink it and remember it's a prototype for the time being. Throw a few essential data fields on the display, drive around with it for a while, and then decide what to keep and what's still missing. Then re-evaluate, re-design, re-test, and re-peat
Similar threads
XTL/XTS5000
Xtl5000 head swap help
