Bug #5119
closed
Jetstream JT270MH in weird state after failed upload
Added by Craig Ross over 6 years ago.
Updated about 4 years ago.
Model affected:
Jetstream JT270MH
I read the instructions above:
Description
I downloaded the latest chirp and tried to program my Jetstream JT-270MH. The read was good and all the feilds were correct included in the two descreet memory locations. hoever upon an upload, the communication crashed and somewhat bricked my radio. I can downlaod and upload from only CHIRP but not from the supplied jetstream software and I no longer have the ability to factory reset the radio via powerup "M" key holding NOR can I access the internal menu. The radio was working 100% prior to the chirp upload. My chirp works with several other radios no problem.
JT-270MH version 107B
Chirp daily build 20170714
Craig Ross KD2CXK
sorry, im running Windows 7 lastest service pack. Using the supplied and working Jetstream USB cable.
- Subject changed from Bricked Jetstream JT270MH to Jetstream JT270MH in weird state after failed upload
- Status changed from New to Feedback
Hi Craig. If you can still power on the radio and upload things (even if just from CHIRP) then the radio isn't bricked. I'm going to change the title of this as that word really scares people.
If you can find a previous image of your radio that was working, I would try to upload that and see if it helps. If you don't have one, let me know and we can try to find you one.
What do you mean by "communication crashed" ? Unfortunately, if a cable gets unplugged during upload, or the radio gets turned off, or a USB driver crashes, there is a good possibility that you can end up in a bad state like this. There's not really anything a piece of software can do about it.
Since you can still upload with CHIRP, blowing a clean image back into the radio is the most likely option for success.
I do not have a clean image. In addition, I can't even default e radio or get into the menu. I have read that these are non-upgradable systems and they are "burned" with their firmware at the factory, to me, that would indicate that they should not able to be damaged is way. So I'm leaning towards something in nvram is corrupted not allowing an overwrite.
But I'm also getting a hardware error which might be a software error masking itself as a hardware error from the actual jetstream programming software. The minute I try to do it either radio read or radio right it fails immediately where the hardware connectivity error but the radio does a soft reset when that happens lasting under one second.
The cable was not moved or damaged during any read or write. It is an incredibly stable machine and I have programmed many radios with it including some directly after this happened. This is either a bug with the new firmware that came on the radio or a chirp problem. It's a brand new rig so it's possible they've done something to the firmware a bit differently that chirp cannot handle. I'm just speculating.
I do have another jet stream but it's the 10 W version. That is bricked. It Powers on to a dual line ""LEIXEN" screen. I never get past that. No other key combinations are possible. I got the radio that way so I do not know what caused it but it does lead me to believe that these are very temperamental radios and you have to do things just right or you have a paperweight which can double as a hand warmer
I don't know about replaceable firmware in these radios, but most if not all are not firmware upgradeable.
Note that we are not uploading firmware when we program these radios, we're just uploading a memory map. Poorly designed radios can be so confused by a bad memory map (however it got in there) that they effectively lock up immediately. I have done this to many Yaesu radios, but I've always been able to work it out. Funnily, the chinese radios seem to be very robust for recovery, but mostly just because of their simplicity. Icom and Kenwood radios are by far the most bulletproof.
Here are the sample images we maintain for our integration tests:
http://d-rats.com/hg/hgwebdir.cgi/chirp.hg/file/c56244c58fe8/tests/images
You might try pushing the matching image into your radio to see if that works or helps. If not, I'm not really sure what to suggest...
I treid to get the image but it doesnt seem to be a recognizable img file for that radio. When I force it in CHIRP, its has bad data fields
I can upload that image but no difference. I still have no access to the menu or the ability to default the radio.
Okay I'm not sure what else to suggest. I've never known an image-based radio to continue to have trouble if it will accept a clean image. The upload process to the radio is really just a straightforward feeding of the image block by block to the device. If it takes it and returns success, there's not much else that can be done from the PC side.
Sorry I don't have something else to offer, but let us know if there's something else you think we can do to help.
well there are a lot of registers CHIRP dosnt support. The factory Jetstream software has fields that chirp doesnt have. I suspect one or more of those are curropted and this might be the issue. Since CHIRP doesnt write to those, how can it give it a entirely clean image? example would be frequancy bounderies.
No, that's actually not how it works. CHIRP downloads an entire image of the radio, and uploads the same. It doesn't expose widgets to twiddle the bits of the image that it doesn't know about, but otherwise the whole thing goes in and out as a unit. If we somehow got part of the image, or a corrupted bit, even in a spot of the image we don't let you twiddle, uploading a full clean image (if the radio will take it) should fix the problem, if it's really something in the memory map. Most of the radios won't even let us only write to certain parts of the memory. If we don't upload a full image the radio will refuse it as soon as we break from the linear address range.
- Status changed from Feedback to Closed
- Target version set to chirp-legacy
No more traffic on this ticket.
Also available in: Atom
PDF