|
I've just released raduino_v1.08. New in this version:
- mode (LSB or USB) of each VFO A and B is now also memorized
- the BITX status (VFO frequencies, modes) is now stored in EEPROM every 10 seconds and retrieved during start up
- a warning message "uncalibrated" is displayed when calibration data has been erased
Download it from Please read the updated operating instructions at
73, Allard PE1NWL
|
Thanks Allard ! Will load it upto the board tonight
73 ON2AAV
|
The eeprom has limited write cycles. It might make sense to write less frequently. Possibly when you switch ?betweeb vfos or toggle the rit. - f
On 27 Apr 2017 10:02 a.m., "ON2AAV" < on2aav@...> wrote: Thanks Allard ! Will load it upto the board tonight
73 ON2AAV
|
All I can say about this release is: Wow!
|
Hi Ashhar,
Thanks for your comment.
Yes I'm aware of this.
That's why we use the EEPROM.put command which uses EEPROM.update() to
perform the write, so it does not rewrite the value if it didn't change.
73, Allard PE1NWL
toggle quoted message
Show quoted text
On Thu, April 27, 2017 18:10, Ashhar Farhan wrote: The eeprom has limited write cycles. It might make sense to write less
frequently. Possibly when you switch betweeb vfos or toggle the rit.
- f
On 27 Apr 2017 10:02 a.m., "ON2AAV" <on2aav@...> wrote:
Thanks Allard !
Will load it upto the board tonight
73 ON2AAV
|
Hi Allard:
I think I side with Ashhar on this. True, the update() method of the EEPROM object only rewrites the data if it has changed from what's currently at that EEPROM address. If I'm engaged in a long QSO, this works fine. However, if I am just "tuning around" looking for someone calling CQ or am looking for a hole where I can call CQ, if I do this for 10 minutes, (which I do a lot when I operate QRP) I perform 60 EEPROM writes for no real reason at all. The next time I turn on my BITX40, I return to whatever random frequency I may have been on during the last 10 seconds before I shut down.
It might make more sense to 1) opt for a much longer delay, or 2) throw it out altogether and replace it with 5 or 10 ?"Favorites Frequencies" (i.e., net control, repeating sked with a friend, watering holes or QRP frequecies, etc.). That way, when I turn on the rig again, I come up in a place that makes some sense rather than a random frequency. Saving a random frequencys would make more sense on a multi-band rig, such as the pending microBITX. However, I will probably code a Favorite Frequencies. The frequencies could be hard-coded at compile time, although it would not be too hard to code it for runtime changes. Because I am using an encoder for frequency tuning and menu selection, I could scroll through my "favorites" list and select the one I want and immediately jump there. It might even be faster than just tuning to that frequency.
Just a thought...
Jack, W8TEE
From: Allard PE1NWL <pe1nwl@...>
To: [email protected]
Sent: Thursday, April 27, 2017 12:41 PM
Subject: Re: [BITX20] raduino_v1.08 released
Hi Ashhar, Thanks for your comment. Yes I'm aware of this. That's why we use the EEPROM.put command which uses EEPROM.update() to perform the write, so it does not rewrite the value if it didn't change. 73, Allard PE1NWL On Thu, April 27, 2017 18:10, Ashhar Farhan wrote: > The eeprom has limited write cycles. It might make sense to write less > frequently. Possibly when you switch? betweeb vfos or toggle the rit. > - f > > On 27 Apr 2017 10:02 a.m., "ON2AAV" < on2aav@...> wrote: > >> Thanks Allard ! >> >> Will load it upto the board tonight >> >> >> 73 ON2AAV >> >> >
|
Or ? c): ?the user explicitly says when to save the state to EEPROM, perhaps with a very long function button push. ?My preference.
On Thu, Apr 27, 2017 at 10:54 am, Jack Purdum wrote: It might make more sense to 1) opt for a much longer delay, or 2) throw it out altogether and replace it with 5 or 10 ?"Favorites Frequencies" ?
|
That would work, too!
Or, d) a combination of the other 3. Perhaps the first 5 are favorites and a 6th is the "button-push" current frequency.
Jack, W8TEE
From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: [email protected]
Sent: Thursday, April 27, 2017 2:01 PM
Subject: Re: [BITX20] raduino_v1.08 released
Or ? c): ?the user explicitly says when to save the state to EEPROM, perhaps with a very long function button push. ?My preference.
On Thu, Apr 27, 2017 at 10:54 am, Jack Purdum wrote:
It might make more sense to 1) opt for a much longer delay, or 2) throw it out altogether and replace it with 5 or 10 ?"Favorites Frequencies" ?
|
Allard gets to decide, one of the few perks of spending weeks straightening all of this out for us. ?I'm fine with his original plan. ? But no point in doing "everything", better to keep the base code simple and understandable. Those that want everything can go hack it themselves easily enough.
On Thu, Apr 27, 2017 at 11:04 am, Jack Purdum wrote: That would work, too!
Or, d) a combination of the other 3. Perhaps the first 5 are favorites and a 6th is the "button-push" current frequency.
?
|
toggle quoted message
Show quoted text
From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: [email protected]
Sent: Thursday, April 27, 2017 2:11 PM
Subject: Re: [BITX20] raduino_v1.08 released
Allard gets to decide, one of the few perks of spending weeks straightening all of this out for us. ?I'm fine with his original plan. ? But no point in doing "everything", better to keep the base code simple and understandable. Those that want everything can go hack it themselves easily enough.
On Thu, Apr 27, 2017 at 11:04 am, Jack Purdum wrote:
That would work, too!
Or, d) a combination of the other 3. Perhaps the first 5 are favorites and a 6th is the "button-push" current frequency.
?
|
Hi Jack, Ashhar,
Thanks for your considerations.
I did following "guestimates", what do you think? Shall we perhaps reduce
the write frequency in the next version?
Atmel guarantees *at least* 100,000 write cycles, but it has been reported
that in reality the max is typically much more than 1M cycles.
Let's assume a max of 1M cycles. Let's also imagine a 'heavy' user who,
*on average* , continuously changes the frequency during 2 hours of
operation, 365 days per year (I believe this is quite extreme usage).
With the current write interval (10 secs), we would have 360 writes/hour.
Per year: 360 x 2 x 365 = 262,800 writes/year
So the life expectancy (in this extreme case) would then be: 1,000,000 /
262,800 = 3.8 years. That may indeed a bit too short.
We could double the write interval from every 10 seconds to every 20
seconds. Life expectancy would then be 7.6 years.
7.6 years still not enough? Then we could extend it to a 30 sec interval.
Life expectancy would then be 11.4 years.
But i.m.o. this is under extreme usage, in reality it will be much longer.
And in the event that some EEPROM cells fail after many years of usage, we
can always move to the next memory page and enjoy another 11 years of
usage.
What do you think?
73, Allard PE1NWL
|
I too feel? that there is? "number of write cycles" limitation, in addition to life of eeprom as regards memory retention. I am sure this is the very aspect? Mr Farhan is bringing out the?? issue related to no of write cycles.
sarma ?vu3zmv
On Fri, Apr 28, 2017 at 12:18 AM, Allard PE1NWL <pe1nwl@...> wrote: Hi Jack, Ashhar,
Thanks for your considerations.
I did following "guestimates", what do you think? Shall we perhaps reduce
the write frequency in the next version?
Atmel guarantees *at least* 100,000 write cycles, but it has been reported
that in reality the max is typically much more than 1M cycles.
Let's assume a max of 1M cycles. Let's also imagine a 'heavy' user who,
*on average* , continuously changes the frequency during 2 hours of
operation, 365 days per year (I believe this is quite extreme usage).
With the current write interval (10 secs), we would have 360 writes/hour.
Per year: 360 x 2 x 365 = 262,800 writes/year
So the life expectancy (in this extreme case) would then be: 1,000,000 /
262,800 = 3.8? years. That may indeed a bit too short.
We could double the write interval from every 10 seconds to every 20
seconds. Life expectancy would then be 7.6 years.
7.6 years still not enough? Then we could extend it to a 30 sec interval.
Life expectancy would then be 11.4 years.
But i.m.o. this is under extreme usage, in reality it will be much longer.
And in the event that some EEPROM cells fail after many years of usage, we
can always move to the next memory page and enjoy another 11 years of
usage.
What do you think?
73, Allard PE1NWL
|
Yes I got the point.
In v1.08 I've set the write interval (quite arbitrarily) to 10 seconds.
What write interval would you advise? Every 10, 20, 30 seconds? Or even
longer?
Or should we choose to abandon this concept alltogether and go for saving
some "favourite frequencies" as Jack and Jerry suggested?
I'm open for any suggestions.
73 Allard PE1NWL
toggle quoted message
Show quoted text
On Thu, April 27, 2017 21:02, Mvs Sarma wrote: I too feel that there is "*number of write cycles*" limitation, in
addition to life of eeprom as regards memory retention. I am sure this is
the very aspect Mr Farhan is bringing out the issue related to no of
write cycles.
sarma
vu3zmv
|
On 28/04/17 07:29, Allard PE1NWL wrote: Or should we choose to abandon this concept alltogether and go for saving
some "favourite frequencies" as Jack and Jerry suggested?
I'm open for any suggestions. Just to be annoying - my suggestion is write only at power-off. ;) Steve
|
Allard:
I agree, for most people it's a "who cares". Perhaps the lesson is: Buy 2 Mega Pro Mini's and when it runs out, plop in the new one. (Another argument for using sockets.)?
Perhaps a germane question is: Why are we saving the frequency in EEPROM on a single-band transceiver anyway? If it's to return to a given frequency later on after we've removed power from the rig, perhaps Jerry's push button is the way to go. Since the Mega has a lot more memory, I may do the Favorite Frequency thing.?
As it stands now, anyone who is worried about the update period can change it. (I did look for update() in 1.08, but couldn't see it??)
Jack, W8TEE
From: Allard PE1NWL <pe1nwl@...>
To: [email protected]
Sent: Thursday, April 27, 2017 2:48 PM
Subject: Re: [BITX20] raduino_v1.08 released
Hi Jack, Ashhar,
Thanks for your considerations.
I did following "guestimates", what do you think? Shall we perhaps reduce
the write frequency in the next version?
Atmel guarantees *at least* 100,000 write cycles, but it has been reported
that in reality the max is typically much more than 1M cycles.
Let's assume a max of 1M cycles. Let's also imagine a 'heavy' user who,
*on average* , continuously changes the frequency during 2 hours of
operation, 365 days per year (I believe this is quite extreme usage).
With the current write interval (10 secs), we would have 360 writes/hour.
Per year: 360 x 2 x 365 = 262,800 writes/year
So the life expectancy (in this extreme case) would then be: 1,000,000 /
262,800 = 3.8? years. That may indeed a bit too short.
We could double the write interval from every 10 seconds to every 20
seconds. Life expectancy would then be 7.6 years.
7.6 years still not enough? Then we could extend it to a 30 sec interval.
Life expectancy would then be 11.4 years.
But i.m.o. this is under extreme usage, in reality it will be much longer.
And in the event that some EEPROM cells fail after many years of usage, we
can always move to the next memory page and enjoy another 11 years of
usage.
What do you think?
73, Allard PE1NWL
|
Loaded the new ver 1.08.
Working great. Like the menus
Thanks very much for your extra efforts improving the operating code.
Keeps getting better....and better
Joe
VE1BWV
On 28/04/17 07:29, Allard PE1NWL wrote:
> Or should we choose to abandon this concept alltogether and go for saving
> some "favourite frequencies" as Jack and Jerry suggested?
>
> I'm open for any suggestions.
Just to be annoying - my suggestion is write only at power-off.? ;)
Steve
|
I personally would love to see it done this way (write at power off) but I have to ask if that is practical. Could we get a reliable write with power being removed at the same time a write is in progress? I love the option of turning the rig on where it was when I turned it off. I had an Icom IC720 in the early 80's that always came back on 7100 every time it was powered up. I hated that "feature"!
Thank you.
Jim Pruitt
WA7DUY
toggle quoted message
Show quoted text
On 4/27/2017 12:32 PM, Steve Wright wrote: Just to be annoying - my suggestion is write only at power-off. ;)
Steve
|
Jack,
the update interval is set at line 1007:
if (millis() - t3 > 10000)
73 Allard PE1NWL
toggle quoted message
Show quoted text
On Thu, April 27, 2017 21:40, Jack Purdum via Groups.Io wrote: As it stands now, anyone who is worried about the update period can change
it. (I did look for update() in 1.08, but couldn't see it??)
|
Jim,
I'm sure this could be done with some extra circuitry using a big
capacitor that can supply power for some extra milliseconds.
Or a 'soft' power switch and an extra relay.
But that is beyond the scope of the standard raduino software as it
involves extra parts and modifications i.m.o.
Unless someone has a clever idea?
73 Allard PE1NWL
toggle quoted message
Show quoted text
On Thu, April 27, 2017 22:10, Jim Pruitt wrote: I personally would love to see it done this way (write at power off) but
I have to ask if that is practical. Could we get a reliable write with
power being removed at the same time a write is in progress? I love the
option of turning the rig on where it was when I turned it off. I had
an Icom IC720 in the early 80's that always came back on 7100 every time
it was powered up. I hated that "feature"!
Thank you.
Jim Pruitt
WA7DUY
On 4/27/2017 12:32 PM, Steve Wright wrote:
Just to be annoying - my suggestion is write only at power-off. ;)
Steve
|
send morse K (dah dit dah) with the Fn button display "saved" when it works
Larry KB3CUF
On Thu, Apr 27, 2017 at 4:25 PM, Allard PE1NWL <pe1nwl@...> wrote: Jim,
I'm sure this could be done with some extra circuitry using a big
capacitor that can supply power for some extra milliseconds.
Or a 'soft' power switch and an extra relay.
But that is beyond the scope of the standard raduino software as it
involves extra parts and modifications i.m.o.
Unless someone has a clever idea?
73 Allard PE1NWL
On Thu, April 27, 2017 22:10, Jim Pruitt wrote:
> I personally would love to see it done this way (write at power off) but
> I have to ask if that is practical.? Could we get a reliable write with
> power being removed at the same time a write is in progress?? I love the
> option of turning the rig on where it was when I turned it off.? I had
> an Icom IC720 in the early 80's that always came back on 7100 every time
> it was powered up.? I hated that "feature"!
>
> Thank you.
>
> Jim Pruitt
>
> WA7DUY
>
>
> On 4/27/2017 12:32 PM, Steve Wright wrote:
>> Just to be annoying - my suggestion is write only at power-off.? ;)
>>
>>
>> Steve
>>
>
>
>
>
|
Allard PE1NWL
ON2AAV