2wayfreq
Member
With the NX-5300, can anyone confirm that ARC4 and AES256 are working fine now on Phase 2 Systems?
-
To anyone looking to acquire commercial radio programming software:
Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.
If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.
To obtain Motorola software see the Sticky in the Motorola forum.
The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.
For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).
This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.
New Firmware release information
- Thread starter kd4efm
- Start date
I think a lot of people have found that firmware updates are like computer hardware drivers – it's best not to update unless you're trying to solve a particular problem or need a particular feature. The last thing I want for my customers is for them to be "fixing" a perfectly good radio. 
I think a lot of people have found that firmware updates are like computer hardware drivers – it's best not to update unless you're trying to solve a particular problem or need a particular feature. The last thing I want for my customers is for them to be "fixing" a perfectly good radio.
Just give it a short time for the 'early adopters' to test it out and if there are no reports of issues here then it's a good sign it's fine. But, yeah, I completely understand what you're saying.
Absolutely, and I hate the fact that Kenwood doesn't disclose firmware notes.I think a lot of people have found that firmware updates are like computer hardware drivers – it's best not to update unless you're trying to solve a particular problem or need a particular feature. The last thing I want for my customers is for them to be "fixing" a perfectly good radio.
An example that comes to mind is the recent change to NX-1300 audio chips that caused a "squeak" that was resolved with a firmware update that can't be used on earlier hardware. That one was well-documented, with serial numbers and everything. Trying to get coders to document their work is like herding cats. Hardware hackers are even more rare and more feral. It takes significant extra work and time getting a proper tech-writer involved to translate the [Japanese-]engineer/coder-speak to human-usable language and they don't do it unless they think it's really necessary.
I do agree that we need more guidance in understanding what to do with a "security update". Is it like computer virus defs that should definitely be applied to close an important hole in, say, encryption key management, or are they closing a hole in their own license key management, and we don't necessarily need to apply it to existing hardware?
It takes significant extra work and time getting a proper tech-writer involved to translate the [Japanese-]engineer/coder-speak to human-usable language and they don't do it unless they think it's really necessary.I do agree that we need more guidance in understanding what to do with a "security update". Is it like computer virus defs that should definitely be applied to close an important hole in, say, encryption key management, or are they closing a hole in their own license key management, and we don't necessarily need to apply it to existing hardware?
I have had FW from Kenwood correct a large issue on a system, but even tech support was surprised when the problem was resolved just by updating FW... So cleary they may not even get great release notes.
I know the FW for the Viking line is developed here in the US, so notes are easier to publish.
Again, we have radios that we made sure we got them to 4.0 because I believe that was the FW that supports arc4 in p25, but they might not have been touched since. Updating firmware should be best practice whenever you do PM's but while you may solve one issue with FW, you create others.
I know the FW for the Viking line is developed here in the US, so notes are easier to publish.
Again, we have radios that we made sure we got them to 4.0 because I believe that was the FW that supports arc4 in p25, but they might not have been touched since. Updating firmware should be best practice whenever you do PM's but while you may solve one issue with FW, you create others.
An example that comes to mind is the recent change to NX-1300 audio chips that caused a "squeak" that was resolved with a firmware update that can't be used on earlier hardware. That one was well-documented, with serial numbers and everything. Trying to get coders to document their work is like herding cats. Hardware hackers are even more rare and more feral.
I do agree that we need more guidance in understanding what to do with a "security update". Is it like computer virus defs that should definitely be applied to close an important hole in, say, encryption key management, or are they closing a hole in their own license key management, and we don't necessarily need to apply it to existing hardware?
I have an NX-1300 that has the issue you describe.. do you know what version this was fixed in? Mine is relatively up to date already though.
If you'll give the first five characters of the serial number and the exact model number and current firmware version, I can tell you if it applies. It's also discussed in service bulletins LSB-0377 and 0378 if you have access. The update has to be obtained from tech support (or your dealer, who should have it or get it).
I PM'd you the info
"Railroad related updates". Interesting.
I think I'm a few behind on my decks...guess I'll update soon...when it drops below 100 degrees heat index.
I think I'm a few behind on my decks...guess I'll update soon...when it drops below 100 degrees heat index.
Might be a setting that changed but anyone else notice after 5.20 even with a pl tone the radio mostly has squelch tails now in scan or parked? In digital conventional sometimes after the transmission the audio has a open squelch as if analog squelch interference is coming through but then drops.
Mine does not have squelch tails except for one ham repeater that has to be CSQ on receive.
Reverted to prior firmware and issue seems to be gone. Checked the channels and pl tone is there, the digital channel is mixed mode with NAC and PL tone.
I should add before on 5.20 the repeater Morse identifier would also come through on the one channel it was parked on. Now it doesn't going one version back.
Last edited:
Sounds like you have/had monitor enabled then.
Double checked and negative.
- Joined
- Feb 28, 2022
- Messages
- 336
Anything worth noting?
