Topics

#qcx QCX Firmware 1.01 released #qcx

Christiaan PA3FUN
 

Hi Hans. Mighty pleased with the profound support you provide for QCX even though I've got some idea of how your agenda looks like :).

Iambic-A now working like a charm - with thanks to Dave 4X1RS and Dany 4X1MJ ! No more need to hook up my straight key anymore.

73's Christiaan PA3FUN

Andy V. Borisenko
 

all OK!
I installed the program on another laptop with Win 10, excluded USB extension cords, and everything worked out!
thank you all and good luck!

Andy V. Borisenko
 

thanks Alan.
I will try again and report on the results.

Alan G4ZFQ
 

trying to insert a screenshot
Andy,

I guess there is a problem with the .hex file. Did you right click and "Save As"?
I cannot see the log text clearly but it seems to have verified the flash.

I suggest the box "Set Fuses" is left unticked. Then if you really want to write fuses use the "Write" button. That way the fuses will only be altered by using the Write button.

73 Alan G4ZFQ

Andy V. Borisenko
 

trying to insert a screenshot

Andy V. Borisenko
 

Good afternoon gentlemen!
I tried to instal firmware T1.01A and failed.
the update did according to the instructions G4ZFQ https://groups.io/g/QRPLabs/topic/qcx_qcx_firmware_1_01/34432918?p=Created,,,20,1,20,0::recentpostdate%2Fsticky,,,20,2,0, 34432918 & jump = 1
after turning on the transceiver, a blank screen and a tone in the headphones. what should I do next? Is my chip broken?
EEPROM I did not touch.

Mike
 

Yep that is what my unit is doing not self decoding...

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 

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

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

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.

Alan G4ZFQ
 

Martin
There is a version 1.0.1a

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

73 Alan G4ZFQ

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

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.

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

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

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 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


 

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

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