Topics

#qcx QCX Firmware 1.01 released #qcx

Kelly Jack
 

Al,

Presume you may have used my gujde to update the firmware. I am monitoring the traffic here to see if it can be determined what is going wrong so that the guide can be updated if necessary.

The following info may be useful.

Operating system
Software
Programming hardware
Original firmware version of the chip
How did you download the firmware
Output from the programming software
Whether you have been able to successfully update the chip previously
Any other variables that may be of note.

73

Simon
VK3ELH

Al Gritzmacher AE2T
 

Hi Simon,

I believe it was your guide (which is well written BTW) that I used. I tried to find your post again to be sure, but couldn't find it among all the "which version of Linux is best" discussion and Windows bashing.

Operating system: Windows 10 Home 64 bit
Software: AVRDUDE 6.3/AVRDUDESS 2.11
Programming hardware: Arduino ISP
Original firmware version of the chip: I believe it was 1.00e
How did you download the firmware: link. Right-click and save-as.
Output from the programming software: Looked normal to me. No errors and finished normally.
Whether you have been able to successfully update the chip previously: I just built the QCX 40. I bought it last summer, but just got around to building it yesterday. Played with it all day and enjoyed it. All seemed normal, but I thought I'd do the software update before I start putting it into an enclosure.

I have experience with Arduinos and RPis and other SBCs. I've used the Arduino ISP sketch before to program other circuits, so this isn't new territory!

After I got the "Use original IC" message, I began reading other posts about it. I found the mentions of the fuses and lock bits and my H value was 0xD9. I used AVRDUDESS to change it to 0xD1 with no effect. The difference between 0xD9 and 0xD1 seems to be a "Preserve EEPROM memory through the Chip Erase cycle" setting. Wish I'd checked it before the fact!

Then I see posts about people needing to restore their eeprom file. My hunch is that, if I had saved the previous eeprom contents before flashing the program, I could put them back.

Or, is it possible that we should be using the GO button below the flash area, instead of the PROGRAM button at the bottom?

One other item, I could not find AVRDUDESS at the link in your writeup. It went to a page for AVRDUDE, but had no mention of AVRDUDESS and most of the sites I found by Googling it were suspicious and I didn't trust them. I finally found it at https://github.com/zkemble/AVRDUDESS, the authors website is https://blog.zakkemble.net/avrdudess-a-gui-for-avrdude/

Thanks for looking into this and if I can help in any way, please let me know.

Al AE2T

 

Alan G4ZFQ
 

Or, is it possible that we should be using the GO button below the flash area, instead of the PROGRAM button at the bottom?
Al, Simon,

I do think the "Go" button is the one to use. It just does the hex flash. "Program" will do everything. This will normally not matter if the other fields are empty but if for any reason something is entered then errors could occur.

Unfortunately it is difficult to establish the reason for the EEPROM erasure. It seems unlikely, but not impossible, that the original chip had incorrect fuse settings. To be certain we need someone reliable to read the fuses before anything else is done.
Copying and saving the Averdude log would help but who would think to do that before closing the program?
If "Program" results in a fuse change then are the fuses changed after the flash is written? If so it would need a second flash before the EEPROM was erased.

Someone did say that saving the EEPROM first then reflashing recovered operation after the erasure. I've not tried that.

73 Alan G4ZFQ

Al Gritzmacher AE2T
 

On Sat, Oct 19, 2019 at 03:17 AM, Alan G4ZFQ wrote:
Or, is it possible that we should be using the GO button below the flash
area, instead of the PROGRAM button at the bottom?
Al, Simon,

I do think the "Go" button is the one to use. It just does the hex
flash. "Program" will do everything. This will normally not matter if
the other fields are empty but if for any reason something is entered
then errors could occur.
Alan,

I had left everything in the eeprom and fuse areas blank assuming that they would not be altered if blank. I did not read the fuse settings until I ran onto trouble, so I can't say what they were initially.
Unfortunately it is difficult to establish the reason for the EEPROM
erasure. It seems unlikely, but not impossible, that the original chip
had incorrect fuse settings. To be certain we need someone reliable to
read the fuses before anything else is done.
Copying and saving the Averdude log would help but who would think to do
that before closing the program?
If "Program" results in a fuse change then are the fuses changed after
the flash is written? If so it would need a second flash before the
EEPROM was erased.

Someone did say that saving the EEPROM first then reflashing recovered
operation after the erasure. I've not tried that.

73 Alan G4ZFQ

In retrospect, reading and saving everything before making a change might have been a good idea. But who does that? We just assume everything will work fine. Until it doesn't! Human nature.

I'm curious, though, why is the .eep file so secretive? Couldn't a default one be posted for use if needed? Could someone read theirs and share it? If there is a menu item that resets the radio to factory settings, I assume it does so by writing the default settings to eeprom. When the program runs and detects the eeprom is blank, why not run that routine instead of telling us "Use original IC?" I suppose only Hans can tell us that.

Reading the help link for fuse settings in AVRDUDESS was a bit informative. Again, in hindsight. It looks to me like the fuse setting may have been incorrect in the chip originally. If it was set to the right value, it should have skipped writing the eeprom.

73,
Al AE2T

Hans Summers
 

Hi Al

I'm curious, though, why is the .eep file so secretive?

Because, I put years of work into this. Work that puts the family's food on the table. I need to protect that as best I can. If anyone has any better suggestions for protecting it feel free to email me (offlist would be fine).

Couldn't a default one be posted for use if needed? Could someone read theirs and share it?

No! See above

If there is a menu item that resets the radio to factory settings, I assume it does so by writing the default settings to eeprom. When the program runs and detects the eeprom is blank, why not run that routine instead of telling us "Use original IC?" I suppose only Hans can tell us that.

See above...

Reading the help link for fuse settings in AVRDUDESS was a bit informative. Again, in hindsight. It looks to me like the fuse setting may have been incorrect in the chip originally. If it was set to the right value, it should have skipped writing the eeprom.

It's not impossible... but, we do use a standard script for writing the chips and so theoretically the result should be the same every time, and in any I've seen this is always the case.

73 Hans G0UPL 

Alan G4ZFQ
 

In retrospect, reading and saving everything before making a change might have been a good idea. But who does that?
Al,

Almost nobody. I think the one that did had seen the problems here first.

I'm curious, though, why is the .eep file so secretive? If there is a menu item that resets the radio to factory
settings, I assume it does so by writing the default settings to eeprom.
When the program runs and detects the eeprom is blank, why not run that
routine instead of telling us "Use original IC?"
Because it stops the firmware being easily used by someone else. The reset maintains that feature. But seems to be defeated if copying works..

It looks to me like the fuse setting may have been incorrect in the chip originally. If it was set to the right value, it should have skipped writing the eeprom.
That's what I was thinking. Hans has said a script is used so it is unlikely to be wrong. A mystery.

73 Alan G4ZFQ

Bill Cromwell
 

Hi,

This has come up several times before. The sad fact is there are so many people who do not respect copyright or patent laws and do not believe in the concept of (othyer people's) intellectual property. Just let somebody steal a penny from one of them and listen to them howl! I have seen it happen:) No sympathy from me.

The big problem with Hans's proprietary software is when he decides to retire or chase a different career (maybe after some sly hacker exposes - steals - his software). There will be no more replacements for the proprietary, protected software. In the meantime Hans seems to be very helpful about those problems.

I have a nice receiver that is filled with prorietary items, most notably the firmware in the microcontroller. The manufacturer has been out of business quite a few years now. Those parts are unobtanium. However, it will be possible to replace the essential functions with new, open source hardware/software. Or adapt an Arduino to operate the still functioning parts in the radio. The same approach can be used if the QRP Labs gear is orphaned some day.

73,

Bill KU8H

On 10/19/19 7:12 AM, Hans Summers wrote:
Hi Al
I'm curious, though, why is the .eep file so secretive?
Because, I put years of work into this. Work that puts the family's food on the table. I need to protect that as best I can. If anyone has any better suggestions for protecting it feel free to email me (offlist would be fine).
Couldn't a default one be posted for use if needed? Could someone
read theirs and share it?
No! See above
If there is a menu item that resets the radio to factory settings, I
assume it does so by writing the default settings to eeprom. When
the program runs and detects the eeprom is blank, why not run that
routine instead of telling us "Use original IC?" I suppose only Hans
can tell us that.
See above...
Reading the help link for fuse settings in AVRDUDESS was a bit
informative. Again, in hindsight. It looks to me like the fuse
setting may have been incorrect in the chip originally. If it was
set to the right value, it should have skipped writing the eeprom.
It's not impossible... but, we do use a standard script for writing the chips and so theoretically the result should be the same every time, and in any I've seen this is always the case.
73 Hans G0UPL
http://qrp-labs.com
--
bark less - wag more

Hans Summers
 

Hi Bill

I have already committed that if at some future point I retire or desist or decease (expectedly or otherwise), in the event that QRP Labs is not sold to or taken over by another, QRP Labs source code will be published openly for the community.

Meanwhile it puts the food on the table and I prefer, not on someone else's table that hasn't done the work :-)

73 Hans G0UPL 


On Sat, Oct 19, 2019, 15:04 Bill Cromwell <wrcromwell@...> wrote:
Hi,

This has come up several times before. The sad fact is there are so many
people who do not respect copyright or patent laws and do not believe in
the concept of (othyer people's) intellectual property. Just let
somebody steal a penny from one of them and listen to them howl! I have
seen it happen:) No sympathy from me.

The big problem with Hans's proprietary software is when he decides to
retire or chase a different career (maybe after some sly hacker exposes
- steals - his software). There will be no more replacements for the
proprietary, protected software. In the meantime Hans seems to be very
helpful about those problems.

I have a nice receiver that is filled with prorietary items, most
notably the firmware in the microcontroller. The manufacturer has been
out of business quite a few years now. Those parts are unobtanium.
However, it will be possible to replace the essential functions with
new, open source hardware/software. Or adapt an Arduino to operate the
still functioning parts in the radio. The same approach can be used if
the QRP Labs gear is orphaned some day.

73,

Bill  KU8H

On 10/19/19 7:12 AM, Hans Summers wrote:
> Hi Al
>
>     I'm curious, though, why is the .eep file so secretive?
>
> Because, I put years of work into this. Work that puts the family's food
> on the table. I need to protect that as best I can. If anyone has any
> better suggestions for protecting it feel free to email me (offlist
> would be fine).
>
>     Couldn't a default one be posted for use if needed? Could someone
>     read theirs and share it?
>
> No! See above
>
>     If there is a menu item that resets the radio to factory settings, I
>     assume it does so by writing the default settings to eeprom. When
>     the program runs and detects the eeprom is blank, why not run that
>     routine instead of telling us "Use original IC?" I suppose only Hans
>     can tell us that.
>
> See above...
>
>     Reading the help link for fuse settings in AVRDUDESS was a bit
>     informative. Again, in hindsight. It looks to me like the fuse
>     setting may have been incorrect in the chip originally. If it was
>     set to the right value, it should have skipped writing the eeprom.
>
> It's not impossible... but, we do use a standard script for writing the
> chips and so theoretically the result should be the same every time, and
> in any I've seen this is always the case.
>
> 73 Hans G0UPL
> http://qrp-labs.com


--
bark less - wag more



Kelly Jack
 

Al, Alan and all,

I've been trying work out what is going on here.

I started with a version 1.00e chip which I have as part of an unbuilt QCX kit.

Started with reading the fuses: the correct High fuse setting was read using avrdudess. 0xD1.

I reprogrammed the chip with firmware version 1.01a successfully a number of times using all permutations of :
Hitting the Go button instead of the Program button and checking the Disable Flash Erase box and the high fuse set at D1 and D9 and the only way I could get the "Use original IC" message was if the fuse was D9 to begin with.

I have tried AVRDUDESS 2.4 with avrdude 6.1 (the versions I had from when I first updated the QCX) and also the latest versions AVRDUDESS 2.11 with avrdude 6.3.

I'm thinking that it can be only one of two things:
1. AVRDUDESS/avrdude is changing the high fuse as part of some bug or hidden setting.
2. The fuse was set incorrectly to start with (unlikely by possible).

I did not see AVRDUDESS reset the fuses to different values of its own accord. That is not to say that there is not a combination of AVRDUDESS/avrdude version, programmer and potentially operating system that can cause this.


Operating system: Windows 10 Pro (64 bit)
Programming hardware: Arduino Uno as ISP
Original firmware version of the chip: 1.00a and 1.00e both successfully reprogrammed.
How did you download the firmware: link. Right-click and save-as.
Output from the programming software: No errors.

I am going to rewrite the guide document to check the fuses first and reset to D1 if required.

73


Simon
VK3ELH

Al Gritzmacher AE2T
 

On Sat, Oct 19, 2019 at 07:12 AM, Hans Summers wrote:
Hi Al

I'm curious, though, why is the .eep file so secretive?

Because, I put years of work into this. Work that puts the family's food on the table. I need to protect that as best I can. If anyone has any better suggestions for protecting it feel free to email me (offlist would be fine).

Couldn't a default one be posted for use if needed? Could someone read theirs and share it?

No! See above

If there is a menu item that resets the radio to factory settings, I assume it does so by writing the default settings to eeprom. When the program runs and detects the eeprom is blank, why not run that routine instead of telling us "Use original IC?" I suppose only Hans can tell us that.

See above...

Reading the help link for fuse settings in AVRDUDESS was a bit informative. Again, in hindsight. It looks to me like the fuse setting may have been incorrect in the chip originally. If it was set to the right value, it should have skipped writing the eeprom.

It's not impossible... but, we do use a standard script for writing the chips and so theoretically the result should be the same every time, and in any I've seen this is always the case.
 
73 Hans G0UPL 
 
 

Hans,

Okay, I understand and respect that. And, I'm willing to take the blame for inadvertently doing something wrong along the way.

The last remaining question is, what do I do now to rectify the problem? I had a working unit yesterday and the firmware update killed it.

Thanks for reading...

Al AE2T


 

Al Gritzmacher AE2T
 

On Sat, Oct 19, 2019 at 09:21 AM, Kelly Jack wrote:
I'm thinking that it can be only one of two things:
1. AVRDUDESS/avrdude is changing the high fuse as part of some bug or hidden setting.
2. The fuse was set incorrectly to start with (unlikely by possible).
or 3. Cosmic rays flipped a bit at random, or some other form of sh!t happens ;) We may never know...

I am going to rewrite the guide document to check the fuses first and reset to D1 if required.
Let me know when you do. I think a cautionary note to backup the original .hex and .eep files and double check the fuse settings is in order.

Thanks, 73,
Al AE2T

Al Gritzmacher AE2T
 

On Sat, Oct 19, 2019 at 08:13 AM, Hans Summers wrote:
Hi Bill
 
I have already committed that if at some future point I retire or desist or decease (expectedly or otherwise), in the event that QRP Labs is not sold to or taken over by another, QRP Labs source code will be published openly for the community.
 
Meanwhile it puts the food on the table and I prefer, not on someone else's table that hasn't done the work :-)
 
73 Hans G0UPL 
I have no problem with this. I'm incapable of reverse engineering the code and duplicating it. If an .eep file were to land in my inbox, I'd swear on a stack of bibles to lose it as soon as it was reloaded. But by the same token, I'm not going to reverse engineer the board, track down the components and duplicate what I can get for $49. It just doesn't make sense. But that doesn't mean someone in China won't. They do it all the time. I'm perfectly happy giving you/Hans my money rather than Aliexpress.

This radio is so nice, I find myself wanting one for 20m. So, I ordered one and added a replacement IC as well. I'll have to wait until it arrives, but meanwhile I'll work on the enclosure for it.

73,

Al AE2T

jmh6@...
 

Hi All,

A lot of good questions and points.

I manufactured with 6502 and had a lot of Hans' concerns.

One day I had a call from one of our OEM customers. He was buying our products and very pleased with them and went on to say he wanted us to change 1 byte in our software....

He had gotten so annoyed he had reverse assembled our code, figured out where our 'mistake' was!!! He was right. I fixed it!!

There are a LOT of very bright people out there!!

He became a life long friend!!

Lots of fun :).

On Sat, 19 Oct 2019, Al Gritzmacher AE2T wrote:

On Sat, Oct 19, 2019 at 08:13 AM, Hans Summers wrote:
Hi Bill  
I have already committed that if at some future point I retire or desist or decease (expectedly or otherwise), in the event that QRP Labs is not sold to or taken over
by another, QRP Labs source code will be published openly for the community.
 
Meanwhile it puts the food on the table and I prefer, not on someone else's table that hasn't done the work :-)
 
73 Hans G0UPL 
http://qrp-labs.com
I have no problem with this. I'm incapable of reverse engineering the code and duplicating it. If an .eep file were to land in my inbox, I'd swear on a stack of bibles to
lose it as soon as it was reloaded. But by the same token, I'm not going to reverse engineer the board, track down the components and duplicate what I can get for $49. It
just doesn't make sense. But that doesn't mean someone in China won't. They do it all the time. I'm perfectly happy giving you/Hans my money rather than Aliexpress.
This radio is so nice, I find myself wanting one for 20m. So, I ordered one and added a replacement IC as well. I'll have to wait until it arrives, but meanwhile I'll work
on the enclosure for it.
73,
Al AE2T

post.marcel@...
 

Not sure if this is relevant, but can I make a suggestion to include a checksum hash for the .hex files on the download page (or in a release-notes file)? I've seen several people in this thread raising concerns about how they should download the .hex file and it created a little unease with myself as to whether the copy-from-the-page-and-paste-into-notepad would leave traces of CRLFs behind that avrdude might trip over. Just a simple MD5 would suffice.

Martin
 

Hi,

from the file history I can see, that there is a version 1.0.1a version but the is that included in this file http://qrp-labs.com/images/qcx/firmware/T1.01.hex ?

73s
Martin
DK3UW

Alan G4ZFQ
 

Martin
There is a version 1.0.1a

http://qrp-labs.com/images/qcx/firmware/T1.01a.hex

73 Alan G4ZFQ

Al Gritzmacher AE2T
 

That would be standard procedure, but I wonder if anyone who doesn't know to right-click the link and use "Save-as" and cuts and pastes the entire file from the browser window, would even know what to do with a MD5 hash.

Putting the .hex file in a .zip package would force it to be downloaded. Revision notes or an updated manual could be put in the same download.

Al Gritzmacher AE2T
 

Hans, Simon, Alan, and everyone else following,

Thanks to Hans coming to my rescue, the QCX 40 is back in operation.

I loaded only the eeprom information and it took off running, which is about what I'd expected.

The hex file did not need to be uploaded again. I think that proves it was probably not a corrupted download.

The fuses remained set to the appropriate values. I did not touch them again. How one got changed previously remains a mystery.

Thanks to all who helped. I hope this helps someone else down the road when they upgrade their software.

Windows 10 Home > AVRDUDESS 2.11 > Arduino UNO as ISP > AVRDUDE from Arduino IDE.

73,

Al AE2T

Mike
 

All,

 Sorry to high jack this post... I loaded the firmware on my QCX and when I power it on I see 1.01 NOT 101a so, I assume that I do not have the latest firmware? Can anyone tell me what the difference between the 2 versions are? 

Thank you!
73's
Mike WA3O

Kelly Jack
 

From the firmware page

1.01a
Bug fix: Decoder didn't work during menu editing and self-decoding your own transmission

73

Simon 
VK3ELH