Well, this sort of thing has been done in the past successfully with other products. Take DD-WRT, for example. Collaboration produced powerful open source firmware that extended the usable life of what was believed to be outdated hardware. I know the x36 line is very capable hardware and not utilized anywhere near its full potential. As long as you aren't stepping on anyone's toes by copying proprietary code or utilizing unlicensed software, etc., I don't think Uniden can stop you. But you would have to separate yourself entirely from Uniden and make it very clear that your firmware is not official or endorsed, etc. I think trying to work with Uniden to update their firmware is a pipe dream for many reasons, unfortunately.
Making our own standalone firmware update
- Thread starter gary123
- Start date
- Status
slicerwizard.
LOL on enabling cellular. I think that could be argued in both directions as a hardware and as a feature. In my opinion it would be a feature modification and not any change to the hardware. That was my point in the reply. There is no hardware changes feature changes well that would be a legal issue and a regulatory one. This is not even being considered but is a major reason that the source code would never be released. We like your input. It points out issues that would normally be missed. However we do not want to turn this thread into what can be done to create issues.
werinshades.
if we ever get to the stage where we are allowed to incorporate changes then yes a you tube video would be in order.
Trucker700.
I see the confusion. Perhaps this example will clarify it. Any good mechanic knows how a 4 stoke engine works. He would have no or little difficulty in describing its general operation in a Ford, GMC or even a Lamborghini. The same applies to the code posted. Its generic a piston is a piston no matter how its customized for the use situation. So is the 'add 1 to a value code'. Its the same functional step in any programming language. C#, VB, Java, ASM, C++, Linux. We chose C# in part because this is a popular language.
LOL on enabling cellular. I think that could be argued in both directions as a hardware and as a feature. In my opinion it would be a feature modification and not any change to the hardware. That was my point in the reply. There is no hardware changes feature changes well that would be a legal issue and a regulatory one. This is not even being considered but is a major reason that the source code would never be released. We like your input. It points out issues that would normally be missed. However we do not want to turn this thread into what can be done to create issues.
werinshades.
if we ever get to the stage where we are allowed to incorporate changes then yes a you tube video would be in order.
Trucker700.
I see the confusion. Perhaps this example will clarify it. Any good mechanic knows how a 4 stoke engine works. He would have no or little difficulty in describing its general operation in a Ford, GMC or even a Lamborghini. The same applies to the code posted. Its generic a piston is a piston no matter how its customized for the use situation. So is the 'add 1 to a value code'. Its the same functional step in any programming language. C#, VB, Java, ASM, C++, Linux. We chose C# in part because this is a popular language.
Last edited:
MStep
Member
I have several pre-code receivers that have cellular band capability. If you like listening to hash noise, they're great. But don't expect to hear much beyond that. Sadly, the days of tuning through the 46.5 - 47 MHz "cordless" range are also over. And remember those great AT&T/Bell 152 MHz channels?
Ubbe
Member
Isn't FCC stating that cellular should be blocked in a way so that a user cannot enable it? They say nothing about hardware or software. Then it can be done solely in software, if that is encrypted to stop it from being tampered with.
What it boils down to are if Unidens costs to support and do quality control, and everything else involved, will make them sell enough more scanners to cover that extra cost with enough overhead to make a profit. They will have that discussion with every little bug fix and feature enhancements that we suggest to "the list". So far they can barely produce enough scanners to cover the demand, even with the current bugs and lack of requested features, and see no reason to increase the demand.
Whistlers dying scanner business are of a much more need to add attractive features and would be a more suitable company to approach, but then they do not have a simulcast capable scanner and that would narrow the customer base.
What are left are to make a firmware from scratch. But what happens with patents and license issues if that firmware are available on GitHub or similar places? Uniden got tons of patents and Whistler too, and then the code for digital decoders are not free.
/Ubbe
I think it was once posted by Paul that you own the scanner Uniden owns the software and firmware.
LOL
Well, do you think they can afford for it to get any worse?
It is indeed a narrow path. If every possible aspect of user/license and other agreements are met technically your not allowed to use the equipment let alone turn it on LOL. For the most part the membership here is realistic. No one is deliberately going to go out and violate agreements etc.
Based on the posts in the tread and a short phone conversation I had with someone in a legal capacity (un solicited but welcome thank you Mr G) these are the allowed options (subject to verification before implementation).
1: Create from scratch new firmware.. This is allowed because the code would be written for the processor and not the hardware. The fact the hardware reacts to the processor commands it irrelevant.
2; post code and fixes, updates and new features in a generic programming (c#) format. Since it is effectively open source it is 100% legal. This is the path we are going to follow.
3: individually get creative on our own hardware. Again allowed under the existing right to repair laws in both USA and Canada.
OK time for the membership to chime in on these items. BUT lets not start another round of sidewalk lawyers arguing minute details lets stick to generalities. Remember this is GENERAL information as such its not the LAW its an interpretation of the laws and common practice. Items 1 and 2 are the most viable.
Based on the posts in the tread and a short phone conversation I had with someone in a legal capacity (un solicited but welcome thank you Mr G) these are the allowed options (subject to verification before implementation).
1: Create from scratch new firmware.. This is allowed because the code would be written for the processor and not the hardware. The fact the hardware reacts to the processor commands it irrelevant.
2; post code and fixes, updates and new features in a generic programming (c#) format. Since it is effectively open source it is 100% legal. This is the path we are going to follow.
3: individually get creative on our own hardware. Again allowed under the existing right to repair laws in both USA and Canada.
OK time for the membership to chime in on these items. BUT lets not start another round of sidewalk lawyers arguing minute details lets stick to generalities. Remember this is GENERAL information as such its not the LAW its an interpretation of the laws and common practice. Items 1 and 2 are the most viable.
MStep
Member
If you're starting from scratch, go for it. It took Uniden years to come up with x36 and the SDS evolutions. If you've got five or six guys working on it, you can probably accomplish it in six months. You don't have all the distractions Uniden had and has--- your team can be fully committed to this one project. I'm sure no one is expecting YouTube videos to appear tonight, but at some point you have to present a proof of concept video, i.e., your own x36 or SDS running on your own software/firmware. Go for it.
MStep.
That is not our first choice but it is on the table. Soooo!!!! Anyone with the interest and skills or other abilities and wants to tackle this project PM me and we will start to build a team. To add to what MStep has said we also have 5 years of additional system information to work with. We also have the vast resource of the RR membership to consult.
That is not our first choice but it is on the table. Soooo!!!! Anyone with the interest and skills or other abilities and wants to tackle this project PM me and we will start to build a team. To add to what MStep has said we also have 5 years of additional system information to work with. We also have the vast resource of the RR membership to consult.
1. Are you going to need beta testers? If so, count me in.
2. New feature request - Bandscope
2. New feature request - Bandscope
I thought you had a team?
belvdr
No longer interested in living
- Joined
- Aug 2, 2013
- Messages
- 2,567
I thought the same.
I would venture a guess and say this is likely not the only thing on the plates of the team.
I'd be surprised if a fully stable firmware was available in a year.
MStep
Member
I also thought that the team was also in place, but perhaps Gary is looking for additional expertise to add to those already involved. And I would also say there is no reason to re-re-reinvent the wheel. I would simply refer you to Joe Bearcat's Help Me Help You thread, where he solicited that very same information on what members were looking for to improve the SDS series. None of those wonderful suggestions ever came to fruition, so this is a big chance for someone to step up and do something about it. Use that list as your starting point and you won't go wrong.
You guys floated the idea and got various degrees of feedback, but I think most of it was along positive lines barring any legal complications. So instead of BettyBearcat, perhaps what we will have is BetterBearcat. Not suggesting that as a name, but so we are all on the same page, I think the first move is to give the project a name. Something recognizable, but not using Bearcat or Uniden in the name. If you plan on making the first firmware and software in the coming months, perhaps something like "Project 2022 / Phase One", or something along those lines, so that everyone has a common point of referral and everyone is on the same page.
You guys have certainly raised some ears and eyebrows!
You guys floated the idea and got various degrees of feedback, but I think most of it was along positive lines barring any legal complications. So instead of BettyBearcat, perhaps what we will have is BetterBearcat. Not suggesting that as a name, but so we are all on the same page, I think the first move is to give the project a name. Something recognizable, but not using Bearcat or Uniden in the name. If you plan on making the first firmware and software in the coming months, perhaps something like "Project 2022 / Phase One", or something along those lines, so that everyone has a common point of referral and everyone is on the same page.
You guys have certainly raised some ears and eyebrows!
Mstep.
yes we are looking for additional members 4 guys is not enough people for such a project. We are all coders, have uniden hardware and are familiar with trunking and decoding in general . As in any group we all bring a something different to the table. To write a whole new software we would want a few who are familiar with capturing CC data converting it to a raw format (generality here), A knowledge of one or more of the formats P25 CAI, DMR, NXDN annndddd TETRA too since I we are making a wish list. We would want someone familiar with the actual hardware specifically the processor. Thats just a start. And yes alpha and beta testers.
I agree a name for the project is essential. Maybe "Gary"s firmware????" no??? oh well it was worth a shot. I open the thread to proposed names.
yes we are looking for additional members 4 guys is not enough people for such a project. We are all coders, have uniden hardware and are familiar with trunking and decoding in general . As in any group we all bring a something different to the table. To write a whole new software we would want a few who are familiar with capturing CC data converting it to a raw format (generality here), A knowledge of one or more of the formats P25 CAI, DMR, NXDN annndddd TETRA too since I we are making a wish list. We would want someone familiar with the actual hardware specifically the processor. Thats just a start. And yes alpha and beta testers.
I agree a name for the project is essential. Maybe "Gary"s firmware????" no??? oh well it was worth a shot.
I open the thread to proposed names.slicerwizard
Member
"Vape"?
Mstep.
yes we are looking for additional members 4 guys is not enough people for such a project. We are all coders, have uniden hardware and are familiar with trunking and decoding in general . As in any group we all bring a something different to the table. To write a whole new software we would want a few who are familiar with capturing CC data converting it to a raw format (generality here), A knowledge of one or more of the formats P25 CAI, DMR, NXDN annndddd TETRA too since I we are making a wish list. We would want someone familiar with the actual hardware specifically the processor. Thats just a start. And yes alpha and beta testers.
I agree a name for the project is essential. Maybe "Gary"s firmware????" no??? oh well it was worth a shot.
Opitz Heroes..LOL!
Annnndddddd....this right here is what is going to put you on Uniden's bad side, and why they will never get behind this. You're already talking about adding new capabilities and functionality to a device that never had it. That's a pretty clear cut case of potentially taking revenue out of Uniden's pocket, and could also result in a breach of licensing if patents are involved.
So what starts out as a seemingly altruistic project to fix bugs and improve performance of existing features, quickly morphs into a shady way to add features without having to pay for or license them.
Frankly, it's a bit perplexing that one would even put all of this out there publicly.
- Status
Similar threads
BCD325P2/BCD996P2:
BC_VUP3 unresponsive when trying to update more than one 325P2/996P2
