Topics

CAT Support uBITX Firmware CEC Version 1.0 Release #ubitx

Ian Lee
 

all
I wanted to do a simple hardware modification, so I early to finished firmware develop.
also almost no space left for the programming, I am going to work on fixing bugs.
This version of the concept is an upgrade without hardware modifications. No hardware modifications are required to use this firmware.



1.Cat communication support. (fldigi, wsjtx, hamradio delux, rpi... more)
2.New Frequency Tune method (threshold applied)
3.Ham band applied (can change general mode)
   (you can select region and adjust ham band by uBITX Manager)
4.CW Keying Change (Ron's code)
5.Key ADC Range adjust by uBITX Manager
6.Split (just VFOA/VOFB)
7.Channel Memory (20 Channels, 10 Channel has Tag (Name) by uBITX Manager)
8.TX Control (Many countries are imposing sanctions on transmittable frequencies.)
   This feature allows uBITX to be used in most countries.
9.Dual VFO Dial lock
10.IF Shift
11.Built in memory keyer (Auto key, CW Text input by uBITX Manager)
    I put a lot of funny features but I could not introduce them.
    For example, Hold during automatic transmission, and the ability to transmit manually and automatically transmit again.
    The ability to select and schedule other text by turning the dial during automatic transmission. more...
   
12.CW Mode (Just set the BFO for CW)
and more...

If you are interested, please refer to the link below. I posted a brief introduction and installation instructions.
There is always a source in the github repository that I am working on.
http://www.hamskey.com

Most of the features are easy to use, but we'll post them on our blogs and youtube for features that require clarification.
https://www.youtube.com/watch?v=9aqkQVioslk

Farhan, who made a very good transceiver, software and playground, and Ron, who improved cw keying, And my best thanks are those who have provided advice, tests and ideas.
(Perhaps somebody is still looking for a bug in the firmware or a feature to add.)

I am going to do some interesting hardware modifications. I'll have to buy a resistor to add a switch.
i will introduce another version that comes with hardware modifications.
-- 
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)

Konstantinos Konstas
 

Thank's Ian, very good effort.
I am running v 0.35 today, but I will upgrade to v 1.0 later on tonight.
Cat interface for ,say FlDigi, is a very useful feature.
Quite happy and Manager assists a lot.

I will come back with more feedback.

73 de Konstantinos, SV1ONW

On 7 February 2018 at 16:27, Ian Lee <kd8cec@...> wrote:
all
I wanted to do a simple hardware modification, so I early to finished firmware develop.
also almost no space left for the programming, I am going to work on fixing bugs.
This version of the concept is an upgrade without hardware modifications. No hardware modifications are required to use this firmware.



1.Cat communication support. (fldigi, wsjtx, hamradio delux, rpi... more)
2.New Frequency Tune method (threshold applied)
3.Ham band applied (can change general mode)
   (you can select region and adjust ham band by uBITX Manager)
4.CW Keying Change (Ron's code)
5.Key ADC Range adjust by uBITX Manager
6.Split (just VFOA/VOFB)
7.Channel Memory (20 Channels, 10 Channel has Tag (Name) by uBITX Manager)
8.TX Control (Many countries are imposing sanctions on transmittable frequencies.)
   This feature allows uBITX to be used in most countries.
9.Dual VFO Dial lock
10.IF Shift
11.Built in memory keyer (Auto key, CW Text input by uBITX Manager)
    I put a lot of funny features but I could not introduce them.
    For example, Hold during automatic transmission, and the ability to transmit manually and automatically transmit again.
    The ability to select and schedule other text by turning the dial during automatic transmission. more...
   
12.CW Mode (Just set the BFO for CW)
and more...

If you are interested, please refer to the link below. I posted a brief introduction and installation instructions.
There is always a source in the github repository that I am working on.
http://www.hamskey.com

Most of the features are easy to use, but we'll post them on our blogs and youtube for features that require clarification.
https://www.youtube.com/watch?v=9aqkQVioslk

Farhan, who made a very good transceiver, software and playground, and Ron, who improved cw keying, And my best thanks are those who have provided advice, tests and ideas.
(Perhaps somebody is still looking for a bug in the firmware or a feature to add.)

I am going to do some interesting hardware modifications. I'll have to buy a resistor to add a switch.
i will introduce another version that comes with hardware modifications.
-- 
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)




--
73 de SV1ONW

Max Lock
 

Thanks Ian for all your hard work, it's really appreciated! :)

I've not played with the ubitx manager as I use Linux, but is the CAT functionality ever likely to emulate the ft-718 memory read/write functionality?

eg.

maxwell@nimbus:~/Desktop$ rigctl --model=120 --set-conf=rig_pathname=/dev/ttyUSB0 -v e
Opened rig model 120, 'FT-817'
get_mem: error = Feature not available


-Cheers Max, G7UOZ.

Philip
 

Hi Max.
I think the firmware has left no room for memory's.

Philip Lock G7JUR

John P
 

Not familiar with your code, but maybe keep the memories in EEPROM. 
--
John - WA2FZW

Konstantinos Konstas
 

Ian,
Speaking of the Manager, it would be nice to run under Linux.
Any chance to play under Wine for example?

73 de Konstantinos, SV1ONW

On 7 February 2018 at 23:17, Max Lock <max@...> wrote:
Thanks Ian for all your hard work, it's really appreciated! :)

I've not played with the ubitx manager as I use Linux, but is the CAT functionality ever likely to emulate the ft-718 memory read/write functionality?

eg.

maxwell@nimbus:~/Desktop$ rigctl --model=120 --set-conf=rig_pathname=/dev/ttyUSB0 -v e
Opened rig model 120, 'FT-817'
get_mem: error = Feature not available


-Cheers Max, G7UOZ.







--
73 de SV1ONW

W2CTX
 

What minimum functions exactly are you looking for in a linux manager?

rOn

Mike Woods
 

There are 20 memory channels in the latest versions (0.35 and 1.0) and they are stored in EEPROM.

Mike


On Thu, 8 Feb 2018 at 11:14 AM, John P <j.m.price@...> wrote:
Not familiar with your code, but maybe keep the memories in EEPROM. 
--
John - WA2FZW

W2CTX
 

I would be careful since EEPROM has a finite write life!
These nano's are soldered in.

rOn



From: Mike Woods <mhwoods@...>
To: BITX20@groups.io
Sent: Wednesday, February 7, 2018 6:27 PM
Subject: Re: [BITX20] CAT Support uBITX Firmware CEC Version 1.0 Release #ubitx

There are 20 memory channels in the latest versions (0.35 and 1.0) and they are stored in EEPROM.

Mike

On Thu, 8 Feb 2018 at 11:14 AM, John P <j.m.price@...> wrote:
Not familiar with your code, but maybe keep the memories in EEPROM. 
--
John - WA2FZW


Ian Lee
 

Konstantinos

Thank you for information.
I ended up trying to starcraft Linux on Linux a long time ago.
using wine is good idea!!!.
If you're using wine on Linux, would you give it a try? I will challenge when the project is over.  And I also trying execute it on mono base.

Your opinion will be helpful.
Thanks agian   Konstantinos

Ian KD8CEC

2018-02-08 7:50 GMT+09:00 Konstantinos Konstas <constantine170@...>:

Ian,
Speaking of the Manager, it would be nice to run under Linux.
Any chance to play under Wine for example?

73 de Konstantinos, SV1ONW

On 7 February 2018 at 23:17, Max Lock <max@...> wrote:
Thanks Ian for all your hard work, it's really appreciated! :)

I've not played with the ubitx manager as I use Linux, but is the CAT functionality ever likely to emulate the ft-718 memory read/write functionality?

eg.

maxwell@nimbus:~/Desktop$ rigctl --model=120 --set-conf=rig_pathname=/dev/ttyUSB0 -v e
Opened rig model 120, 'FT-817'
get_mem: error = Feature not available


-Cheers Max, G7UOZ.







--
73 de SV1ONW



--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)

Ian Lee
 

Max
I have not used rigctl in command mode.  I'll try the rigctl command if I have a chance. 

In FT-817 compliant CAT control, eeprom read / write is rarely used. 
VFOA / VFOB conversion, get / set cw speed, get / set side tone, and get split status. 
I have run several programs and checking which using protocol with the logic analyzer.
and uBITX emulated only necessary protocols. So things that are not needed in uBITX like FT-817's output adjustment, antenna connector position, etc. will not be controlled.

Instead I created a new protocol for just uBITX eeprom control.
I made it so simple that it can be applied to all firmware within 20 lines of code.
uBITX Manager uses this protocol. 
uBITX Manager does not use FT-817 protocol but uses uBITX proprietary protocol, so it can not be controlled by general purpose program.


I am happy to get a lot of information while starting amateur radio again.

Ian KD8CEC

2018-02-08 6:17 GMT+09:00 Max Lock <max@...>:

Thanks Ian for all your hard work, it's really appreciated! :)

I've not played with the ubitx manager as I use Linux, but is the CAT functionality ever likely to emulate the ft-718 memory read/write functionality?

eg.

maxwell@nimbus:~/Desktop$ rigctl --model=120 --set-conf=rig_pathname=/dev/ttyUSB0 -v e
Opened rig model 120, 'FT-817'
get_mem: error = Feature not available


-Cheers Max, G7UOZ.






--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)

Ian Lee
 

Philip 

Yes, that's right. I made various attempts to put a lot of features into a small space.
Any attempt was good. (ex:change method using strings, Applying new logic to display frequencies ...)
However, there were times when I did not see the effect. (ex : Merge menus - Put all the toggle menus functionality in one function, Put all the use encoder menus functionality in one function)
I was able to save a little bit of flash memory, but the code was quite complicated. So I erased those codes and recover before sources.
For CAT communication, i implemented only protocols that uBITX can use.

Ian KD8CEC



2018-02-08 7:11 GMT+09:00 Philip <philip.g7jur@...>:

Hi Max.
I think the firmware has left no room for memory's.

Philip Lock G7JUR



--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)

Jerry Gaffke
 

In section 8.4 of the ATmega328P datasheet (used on the Nano, which is used on the Raduino) 
    (EEPROM) is organized as a separate data space, in which single bytes can be read and written.
    The EEPROM has an endurance of at least 100,000 write/erase cycles.
So can update each individual byte 100,000 times.
Hard to imagine burning out an EEPROM byte if it involved twiddling knobs and pressing some buttons for each update.

Where you get into trouble is when the code writes to EEPROM with no operator intervention.
Takes about 3.4ms to erase and write an eeprom byte, so a code loop could burn out a byte of eeprom in about an hour.


On Wed, Feb 7, 2018 at 03:49 pm, Ronald Pfeiffer wrote:
would be careful since EEPROM has a finite write life!
These nano's are soldered in.
 
rOn
 
From: Mike Woods <mhwoods@...>   Sent: Wednesday, February 7, 2018 6:27 PM
There are 20 memory channels in the latest versions (0.35 and 1.0) and they are stored in EEPROM

W2CTX
 

You can eat up 100,000 writes.  Each time you change any menu item
it gets stored in EEPROM.  Ian also automatically stores the current
frequency each time you change it.

Also I meant after several years when users get intermittent errors
for no apparent reason!

rOn



From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: BITX20@groups.io
Sent: Wednesday, February 7, 2018 8:44 PM
Subject: Re: [BITX20] CAT Support uBITX Firmware CEC Version 1.0 Release #ubitx

In section 8.4 of the ATmega328P datasheet (used on the Nano, which is used on the Raduino) 
    (EEPROM) is organized as a separate data space, in which single bytes can be read and written.
    The EEPROM has an endurance of at least 100,000 write/erase cycles.
So can update each individual byte 100,000 times.
Hard to imagine burning out an EEPROM byte if it involved twiddling knobs and pressing some buttons for each update.

Where you get into trouble is when the code writes to EEPROM with no operator intervention.
Takes about 3.4ms to erase and write an eeprom byte, so a code loop could burn out a byte of eeprom in about an hour.


On Wed, Feb 7, 2018 at 03:49 pm, Ronald Pfeiffer wrote:
would be careful since EEPROM has a finite write life!
These nano's are soldered in.
 
rOn
 
From: Mike Woods <mhwoods@...>   Sent: Wednesday, February 7, 2018 6:27 PM
There are 20 memory channels in the latest versions (0.35 and 1.0) and they are stored in EEPROM


Ian Lee
 

Thanks for very important information.

The lifetime of the eeprom guaranteed by the vendor is 100,000 write cycle. read cycle is unlimited.
One thing to note is 100,000 times per memory address.
It is not important how many eeprom addresses are used, but how much is written to one eeprom address is important.
There is no problem with using a typical eeprom. 100,000 times more than thought is very large.
Some people say that they have used more than 100,000 through the experiment, but it is better to use the range that the vendor guarantees.

Experience has shown that the eeprom lifetime error is one case.
It is a periodic write to one memory address.
The most vulnerable is to use eeprom in loops like for and while, or to use the eeprom periodically in the timer.

In case of uBITX, cyclic frequency(with mode) storage to eeprom will be a problem to automatically display the frequency that was used previously when the radio is turned on and off.

If you save every 5 seconds, 720 writes occur in 1 hour. The life of the eeprom guaranteed by the vendor is only 138 hours. If use it for 2 hours every day, the life time of 70 days is over.
Of course, the actual life of the eeprom is much longer than the number of times it is guaranteed by the business. Because we are not always lucky, i will not discuss it here.

So, I am actively agreeing with ron's important information.

I have put some of safeguards in my firmware to take into account the life of the eeprom.
The first is virtual eeprom. I created the same variable as eeprom that I had to write periodically and put it in memory.
Compared to the contents of memory before writing to eeprom, I made it write if it changed.
This avoids unnecessarily wasting the write cycle on a periodic basis and preventing the CPU usable
Another was to identify the intent of the user. In other words, if the frequency is changing rapidly, the user is turning the knob.
That is, if the frequency is changing, it will skip even if the periodic storage time is reached.

Always be careful when using eeprom in loop statements or timers.

Ian KD8CEC

2018-02-08 8:49 GMT+09:00 Ronald Pfeiffer via Groups.Io <w2ctx@...>:

I would be careful since EEPROM has a finite write life!
These nano's are soldered in.

rOn



From: Mike Woods <mhwoods@...>
To: BITX20@groups.io
Sent: Wednesday, February 7, 2018 6:27 PM
Subject: Re: [BITX20] CAT Support uBITX Firmware CEC Version 1.0 Release #ubitx

There are 20 memory channels in the latest versions (0.35 and 1.0) and they are stored in EEPROM.

Mike

On Thu, 8 Feb 2018 at 11:14 AM, John P <j.m.price@...> wrote:
Not familiar with your code, but maybe keep the memories in EEPROM. 
--
John - WA2FZW




--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)

Ian Lee
 

Jerry.

You wrote while I was writing a long story.

Yes. There is a problem when writing to the eeprom periodically. so Various avoidance methods are used.
Increased conditions for writing eeprom, sequential writing of multiple eeproms, random access, 
If you are interested, you can see how I avoided the eeprom life time in my code.
I've used Arduino for the first time, but the firmware has been working in various project for quite some time. 
So I check the datasheet before you start the project like you.
For parts with life cycle such as eeprom, relay, etc., calculations must be done first.

Thanks you good information.

Ian KD8CEC

2018-02-08 10:43 GMT+09:00 Jerry Gaffke via Groups.Io <jgaffke@...>:

In section 8.4 of the ATmega328P datasheet (used on the Nano, which is used on the Raduino) 
    (EEPROM) is organized as a separate data space, in which single bytes can be read and written.
    The EEPROM has an endurance of at least 100,000 write/erase cycles.
So can update each individual byte 100,000 times.
Hard to imagine burning out an EEPROM byte if it involved twiddling knobs and pressing some buttons for each update.

Where you get into trouble is when the code writes to EEPROM with no operator intervention.
Takes about 3.4ms to erase and write an eeprom byte, so a code loop could burn out a byte of eeprom in about an hour.


On Wed, Feb 7, 2018 at 03:49 pm, Ronald Pfeiffer wrote:
would be careful since EEPROM has a finite write life!
These nano's are soldered in.
 
rOn
 
From: Mike Woods <mhwoods@...>   Sent: Wednesday, February 7, 2018 6:27 PM
There are 20 memory channels in the latest versions (0.35 and 1.0) and they are stored in EEPROM



--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)

Ian Lee
 

Ron

You wrote while I was writing a long story.
Thank you for your excellent advice. I have been studying a lot.
I will do calculate and simulation write cycle time one more time.

Ian KD8CEC




2018-02-08 10:58 GMT+09:00 Ronald Pfeiffer via Groups.Io <w2ctx@...>:

You can eat up 100,000 writes.  Each time you change any menu item
it gets stored in EEPROM.  Ian also automatically stores the current
frequency each time you change it.

Also I meant after several years when users get intermittent errors
for no apparent reason!

rOn



From: Jerry Gaffke via Groups.Io <jgaffke=yahoo.com@groups.io>
To: BITX20@groups.io
Sent: Wednesday, February 7, 2018 8:44 PM
Subject: Re: [BITX20] CAT Support uBITX Firmware CEC Version 1.0 Release #ubitx

In section 8.4 of the ATmega328P datasheet (used on the Nano, which is used on the Raduino) 
    (EEPROM) is organized as a separate data space, in which single bytes can be read and written.
    The EEPROM has an endurance of at least 100,000 write/erase cycles.
So can update each individual byte 100,000 times.
Hard to imagine burning out an EEPROM byte if it involved twiddling knobs and pressing some buttons for each update.

Where you get into trouble is when the code writes to EEPROM with no operator intervention.
Takes about 3.4ms to erase and write an eeprom byte, so a code loop could burn out a byte of eeprom in about an hour.


On Wed, Feb 7, 2018 at 03:49 pm, Ronald Pfeiffer wrote:
would be careful since EEPROM has a finite write life!
These nano's are soldered in.
 
rOn
 
From: Mike Woods <mhwoods@...>   Sent: Wednesday, February 7, 2018 6:27 PM
There are 20 memory channels in the latest versions (0.35 and 1.0) and they are stored in EEPROM




--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)

Nick VK4PP
 

Another trick I have seen to save EEPROM life:
It is used in an Arduino Antenna Rotator, is to monitor the 12V via a voltage divider and Analog port.
When the voltage drops maybe 1V below "normal", as seen at startup, write settings to eeprom only then.

When you power off the radio the 5volt regulator + input capacitor should hold up the Arduino for just long enough to catch the voltage dropping and write the last used frequency to memory....

73, Nik, VK4PLN

Jack, W8TEE
 

I had a situation where I wanted to insure that, when the user restarted their transceiver, it would show the last-used frequency. The problem is you don't know when they are going to turn the rig off. Sure, there are ways to do things after power is removed, but this was a QRP rig where cost was a primary concern. What I did was use one of the Nano's timers to try to determine what the user was doing. If the frequency is changing in short intervals, say once every second, chances are they are tuning around on the band. If they have not changed frequency in the past XX seconds, I updated the EEPROM with that frequency, provided that the EEPROM frequency is different from the current operating frequency. That way, if the user is monitoring a net frequency for an hour or is away doing something but the rig is still on, no EEPROM updates are done. EEPROM reads have no life cycle, so if they are just tuning around or if they are "parked" on a frequency, this approach can extend the lifetime of the EEPROM.

Jack, W8TEE



From: Ian Lee <kd8cec@...>
To: BITX20@groups.io
Sent: Wednesday, February 7, 2018 9:08 PM
Subject: Re: [BITX20] CAT Support uBITX Firmware CEC Version 1.0 Release #ubitx

Thanks for very important information.

The lifetime of the eeprom guaranteed by the vendor is 100,000 write cycle. read cycle is unlimited.
One thing to note is 100,000 times per memory address.
It is not important how many eeprom addresses are used, but how much is written to one eeprom address is important.
There is no problem with using a typical eeprom. 100,000 times more than thought is very large.
Some people say that they have used more than 100,000 through the experiment, but it is better to use the range that the vendor guarantees.

Experience has shown that the eeprom lifetime error is one case.
It is a periodic write to one memory address.
The most vulnerable is to use eeprom in loops like for and while, or to use the eeprom periodically in the timer.

In case of uBITX, cyclic frequency(with mode) storage to eeprom will be a problem to automatically display the frequency that was used previously when the radio is turned on and off.

If you save every 5 seconds, 720 writes occur in 1 hour. The life of the eeprom guaranteed by the vendor is only 138 hours. If use it for 2 hours every day, the life time of 70 days is over.
Of course, the actual life of the eeprom is much longer than the number of times it is guaranteed by the business. Because we are not always lucky, i will not discuss it here.

So, I am actively agreeing with ron's important information.

I have put some of safeguards in my firmware to take into account the life of the eeprom.
The first is virtual eeprom. I created the same variable as eeprom that I had to write periodically and put it in memory.
Compared to the contents of memory before writing to eeprom, I made it write if it changed.
This avoids unnecessarily wasting the write cycle on a periodic basis and preventing the CPU usable
Another was to identify the intent of the user. In other words, if the frequency is changing rapidly, the user is turning the knob.
That is, if the frequency is changing, it will skip even if the periodic storage time is reached.

Always be careful when using eeprom in loop statements or timers.

Ian KD8CEC

2018-02-08 8:49 GMT+09:00 Ronald Pfeiffer via Groups.Io <w2ctx@...>:
I would be careful since EEPROM has a finite write life!
These nano's are soldered in.

rOn



From: Mike Woods <mhwoods@...>
To: BITX20@groups.io
Sent: Wednesday, February 7, 2018 6:27 PM
Subject: Re: [BITX20] CAT Support uBITX Firmware CEC Version 1.0 Release #ubitx

There are 20 memory channels in the latest versions (0.35 and 1.0) and they are stored in EEPROM.

Mike

On Thu, 8 Feb 2018 at 11:14 AM, John P <j.m.price@...> wrote:
Not familiar with your code, but maybe keep the memories in EEPROM. 
--
John - WA2FZW




--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)


Ian Lee
 

Nik
Good Idea!!!

It is amazing to be solved with only one capacitor. Since the LCD consumes quite a lot of current, I need to calculate the capacitance capacity.
I have been thinking a lot about reducing program memory size.
If this method is applied to my hardware modified version firmware, the program size can be reduced. This is because you can remove code that takes into account the lifetime of the eeprom.

Thanks for great idea

Ian KD8CEC

2018-02-08 11:49 GMT+09:00 Nick VK4PLN <nickpullen@...>:

Another trick I have seen to save EEPROM life:
It is used in an Arduino Antenna Rotator, is to monitor the 12V via a voltage divider and Analog port.
When the voltage drops maybe 1V below "normal", as seen at startup, write settings to eeprom only then.

When you power off the radio the 5volt regulator + input capacitor should hold up the Arduino for just long enough to catch the voltage dropping and write the last used frequency to memory....

73, Nik, VK4PLN



--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
www.hamskey.com (my blog)