Corrected the link in Ron’s message.

whats funny a while abck someone moaned that the CEC code doesn't fit anymore
I did a what about Nano Every at 48K flash, more ram, less EEprom.

Crickets...

Allison
------------------
Please use the forum, offline and private will go to bit bucket.

Ron,

That is great! I have heard others have tried this, but not a lot of folks have taken this path.

There might be some issues running Nano Every with KD8CEC as the Nano every only has 256 bytes of EEPROM where the Nano has 1024 bytes. And KD8CEC stores a lot of stuff up above 256 including your call sign, etc. If you have the source code, take a look at the file ubitx_eemap.h. Anything above 256 will not be saved in the eeprom because it stops at 256...Have you tried the uBITX memory manager with your Nano Every? Bet it will not work as it insists of reading 1204 bytes... 

In regards to non-nano Raduinos and a ported version of KD8CEC running on them, you might want to look at www.github.com/aj6cu  I have ported KD8CEC to Nano IOT, Nano BLE, Nano RP2060, and Teensy 4.0 and there exists corresponding gerbers. The latest gerbers (v1.4) support all version of uBITX from v3 to v6.. There is an external EEPROM (connected over I2C) that provides 4k bytes (only using 1k at the moment). At one point, I did have it working on the Nano Every, but messed something up as I was chasing after the bigger processors first. (I believe it has something to do with how I ripped out the mini software serial library and replaced it with the real thing...) Or it is possible I have a dead Nano Every too :-)

There are lots of other bugs I am still chasing, wspr is broken, CW keyer is broken, and the LCD displays don't work yet. It might take a few weeks before I get back to the Nano Every.

I would be interested in hearing how it goes with you. KD8CEC quite frankly has a lot of cruft stored in the EEPROM, and the only OEM software only used <100 bytes. So it is *very* possible that you will never see any real missing functionality.

Here is a video of KD8CEC running on the Teensy 4.0 processor on a uBITX v3.  https://www.youtube.com/watch?v=-vJm-45OTe8&ab_channel=MarkHatch 

At the moment, my V6 uBITX is running one of my V1.4 boards with KD8CEC V1.2 and a plain old Nano. It is providing a basis for comparison of my port efforts

73
Mark
AJ6CU

The memory manager needs edits to run on devices with small EEprom,
It assumes the device is larger.  It also uses some to keep track of errors.

Exactly what does it store that 256 is not enough?

I have one running the really old base code Raduino and it works just
fine. Also tried a VFO code I used for a different radio and the testbed 
runs without changes (serial LCD, band switching signals, encoder,
SI5351).

A few test cases for Ad8950 based VFO with 4 linex20 display.
All behave the same.

Allison
------------------
Please use the forum, offline and private will go to bit bucket.

Guys, this program was written to KEEP FROM using the CEC software and the expensive NEXTION displays.  It functions much better than the original factory software and has a (my opinion) nicer display layout.  It was done to provide a less expensive means of improving the uBITX V6 operation and even comparing it to CEC's software was never intended.  Our software doesn't have the fancy waterfall display but it wasn't intended in the first place.  It takes the very expensive nextion display to do that and We do NOT believe in modifying the uBITX to use it.  By the way folks, where IS KD8CEC anyway?  I have seen nothing from him in over 2 years now so he is apparently NOT providing any further support for his software.

With Ron's NANO Every version, if you have an AGC installed and can pick off an output for the S meter that has a MAX output of 5 volts, connect it to the Encoder plug on the Raduino, labeled "Spare" and in the Set menu of the Every software, turn the S meter to ON and set the calibration number to 25.  It Will give you a nice S meter bar graph at the top of the screen.  If you have an accurate 50 microvolt RF source, connect it to the uBITX antenna and vary that calibration number until it reads S-9 on the bargraph. 

You can read about this software version on TSW's website, www.w0eb.com and the program is available there for download.  Click on the "Program & DOC Files" selector at the top of the page and then click on the NANO_EVERY_Program selector near the bottom of the page to get to that download directory.  The downloadable zip file contains the initialization program, the instruction manual and the Version 1 release software.
One thing of note, the V1 program there now has a slight bug that is being worked on right now and that is in "Manual" (hand key) mode, the connection goes to the wrong pin (sleeve instead of tip) on the CW Key Jack.

I just finished a really nice QSO with NO8C on one of the SKCC 20 meter frequencies with S9 signals both ways.  I Was using a hand key (work around for the but, select "Cootie" instead of Manual and your hand key will work fine.
You can also plug a Bug into the key jack while in "Cootie" mode.  Oh yes, a "Cootie" key works too, LOL.

Jim Sheldon, W0EB
TSW Project Coordinator

Allison,

Without a doubt, there is a lot of cruft or obsolete info stored in that area above 256 (e.g.- lbf filter customization, SDR mode, and far too much eeprom memory allocated to a resister network (similar to T-41 design) based push button to get around not enough digital/analog pins).

However, if we were to chop off everything above 256 we would loose:
1. Regional band setting without recompilation
2. The enhancements for tweaking the ADC response to CW dits/dahs for more accuracy - The increased reliability of KD8CEC for CW stems from this info
3. CW TX start delay, TX extended timings
4. Tuning step control without recompilation
5. Tweaking the IF shift without messing with calibration.
6. WSPR
7. Auto Keyer for CW
8. Stored/retrival of Callsign for autokeyer
9. Memory channels (both named and unamed)

And I agree, the uBITX Memory Manager should be more robust (and I would add crossplatform). with 20-20 hindsight, pretty silly to have assume 1024 forever. The uBITX memory manager that I have under development (see https://github.com/AJ6CU/uBITX-EEPROM-Manager ) recognizes different size EEPROM possibilities at the #define level. However, I have to admit that this is still a feature for a future version...  

73
Mark
AJ6CU

To that I say, depends what you want or need.

I ran though that gauntlet back 2018 and I got tired of it.
A lot of flailing later...  same stuff, different day.

I care not about wspr, if I did it I'd use a simpler radio
for a committed application.

And a long list of things...


Allison
------------------
Please use the forum, offline and private will go to bit bucket.

Jim,

I certainly respect your design decision to jettison the Nextion for cost and noise issues (although I have not personally seen the latter). However, having worked for an engineering company that specialized in user interfaces for much of my career, it is in my DNA to prefer a little more "eye-candy" and functionality. There was actually a posting a few months back about a V6 owner that hated all touch screens and just wanted knobs! So I guess there is at least one more frame of reference. ;-)

I agree that Dr. Lee has gone silent and is not doing anything on KD8CEC. But that doesn't mean nothing is happening. Although I have only been working on KD8CEC for the last 6 months or so, you might want to checkout http://www.github.com/aj6cu

1. Collects all the Nextion screens I could find in one place and adds support for the new screens coming off the production line that require use of the latest Nextion editor
2. Open source designs for Raduinos that support Arduino Nano, Nano Every, Arduino IOT, BLE and RP Connect, Teensy 4.0, and Raspberry Pi Pico. These were all done using KiCAD and the design files are there for *real hardware* engineers to improve and extend. The latest turn of these boards support all versions of uBITX from V3-V6. 
3. "V2.0" of KD8CEC that has been ported to these platforms (except the Pico which needs the encoder re-located, and a current bug with the Nano Every fixed). 
4. Rewrite of the uBTIX Memory Manager in python for portability and to support this new hardware. At the moment, I have backup, restore, and the generation/application of a XML "user modifiable" file for customization. A fully GUI version that will work on Windows, Mac and Linux is my current project.
5. Several daughter boards - independent 5v power supply + the "2nd nano I2C" board for SWR and S-Meter.

KD8CEC needs a major rewrite post V2.0. The screen communication architecture needs to be virtualized so that less expensive touchscreens can be used in addition to the Nextions. The underlying hardware/radio architecture could use some attention to so it could be re-used for new designs as they appear.
 
i would also like to move KD8CECto a more "rtos" like overall architecture with at least process/scheduling handled by a supervisor. FreeRTOS is probably an overkill here, but there are other lighter weight options. And i suspect it comes as no surprise, Dr. Lee was far too crafty in his attempts to save memory (well it was a nano after all) and that creates all sorts of maintenance headaches...

73
Mark
AJ6CU

A recompile with if-def's for much of that stuff seems fine.
Anybody installing that software needs to navigate the Arduino IDE anyway.

Any modern processor will have far more flash than a Nano.
Should be able to allocate two blocks of flash to replace lost EEPROM.
One is active, the other gets erased and written to with updated data when a change is made,
and then it becomes the active block.
Or format as one block of addr:data pairs, zero out any pair that gets changed
and write a new addr:data pair further down the block to replace it.
Not claiming it's easy, but I do think it is possible.

I'm all for removing cruft that sees little use.
A hacker's rig should be easy to understand.

Jerry, KE7ER

Allison,

Yup, you are right. sort of depends on what your goals are here. I am sure you are not alone with your preferences. :-)

So you are a SSB guy? ;-) My understanding is that the CW enhancements were the first success in making CW practical on uBITX.  Of course, that is all old news and *all* the new firmware these days has fixed this problem. Just loosing that feature because it doesn't fit in 256 make KD8CEC not a good fit for CW. (To be fair, the code actually implements these features so even without the EEPROM support you could always go to the code and adjust the ADC settings and see whether things are better or not..)

73
Mark
AJ6CU

Jerry,

Fair point on using some of the flash of the newer processors for EEPROM emulation. Many processors have that library (know specifically Teensy 4.x and Pico do). I didn't go in that direction because of the fear of "flash wearout" of the processor. I suspect that is a silly excuse and if I looked at it, the mathematics would suggest that I would be a SK long before that happened....

But the external I2C EEPROM chip was something like $2 each, and that meant that I didn't have to add (and test) additional #ifdefs for different eeprom emulation. So I made a different decision here.

73
Mark
AJ6CU 

Mark,

Mostly SSB VHF and up and CW when forced or desperate.
I also do everything else.  Partly becase I'm QRV from 160
up to 432 and adding 1296.

As to uBitx... Its an SSB radio (includes data).  If I wanted CW 
it would have a narrower filter to start with and then better audio
as part of the base design and not even bother with SSB.  I'm that
noxious one that has asked if your into CW why why a primarily
SSB radio?   Add to that my primary radios include 4 Tentec that
do QSK and CW well and a IC7300 and a few others that point
out why CW on a primarily SSB radio is always less than optimum.
Even not being a CW leaning sort having radios that do it well
spoils one.  One I really like is the kitsandparts.com 1W one puny
watt but clean and sweetest sidetone and runs for days on a
stack of penlite cells.  

I arrived at the point while -bitx- is a hackers aradio (Me, me, me)
trying to make it into a baby IcKenYae is reaching for the ridiculous
even if its for fun.   To crib a line. Zero in on its best thing or
ability and make it, the best of the best for that.


Allison
------------------
Please use the forum, offline and private will go to bit bucket.

Allison,

Agree with you on your criticism of uBITX and CW. But couldn't help yanking your chain a little. Sorry ;-)

I am working on KD8CEC exactly because the source code is open and the uBITX is hackable. Doing this for fun and my first hobby after real retirement. In my dreams, I would like to turn this into a general open source ham radio firmware that can be adopted to new radios (hence the thoughts on virtualizing the radio and screen hardware). But I suspect this will be done (or not done) by the next guy that takes over this software.

73
Mark
AJ6CU

The Nano Every came to my rescue on my Furlogh 2040 SSB transceiver.  And I love using it with the Nextion display.  Honestly, the argument about expense feels a little over wrought. By the time you add in the cost of a Teensy and a nice TFT, you're in the ballpark.  

Mark, I have virtualized the GUI in my SSB radio build.  I have a common set of functions that work on a 4x20 LCD, a TFT, or the Nextion.  The Nextion has additional features, but  a single #define switches in the correct function bodies.

Mark,

I know you were yanking the chain.  But the point was aimed at them
not you.  It was clear you understand.

Oh, and desperate is everyone is FT8 and I want a VHF contest QSO
where I can ask the OPS name.

Having retired in 2018 and at the same time I have things I really want
to do ubitx had to come to a logical conclusion and more on.


Allison
------------------
Please use the forum, offline and private will go to bit bucket.

Dean,

Thank you! Took a peek at the Nextion part of the code, Wow! What great documentation. The protocol that is used to talk to the Nextion with KD8CEC is one of the more obscure parts of his code. The documentation you have there is great! And I really like that you used the real Nextion library.  Think that KD8CEC was asking for trouble by rolling his own and then using triggers and timers everywhere in his Nextion hmi files.... That is a part of his code that makes adding new display designs almost impossible... The graphs he dies are *very very* difficult to work with.

How does your encoder work. Didn't dig into it deeply, but looked like just a typical digital pin approach? Have to move the KD8CEC encoder off the analog pins because the Raspberry Pi Pico does not have enough Analog pins... Do you mind if I try it out in KD8CEC?

Once i get 2.0 stabalized and out, will circle back to your work. I think you have a lot of good stuff there!

73
Mark
AJ6CU

Hi Mark,

I have to document because otherwise I forget!  The older I get the less I remember.    The rotary encoder borrows from a library by Ben Buxton from 2011 that I modified slightly.  It uses digitalread so no analogue silliness.  My implementation uses interrupts - which vary by device.  I have code for the Nano and the Nano Every.  I use a very simple increment/decrement algorithm for the encoder.  It works very smoothly and never misses.

I think I have mentioned before that Dr. Lee is a bit too clever for me.  I gave up on trying to figure out his Nextion implementation. I did some experimentation before settling on the Nextion library.  There is a fairly vocal group of "Nextion Library Critics" on the Arduino board. There are alternate libraries and approaches that all have their own problems and challenges.  I like the object oriented approach that Nextion took and find it pretty easy to use.  It is memory hungry, but if you look at the code, you'll see I didn't use many of the IDE objects directly - instead I just construct and send a simple command to update the screen.  I also don't do much processing on the Nextion.   I could probably do a bit more - but I find the IDE and programming environment a bit clunk and I generally prefer to keep the main program logic all in one place. That's partly how I maintain interface compatibility with multiple display types.  The one thing I did do in the Nextion was frequency scanning - that turned out to be easy and I didn't have to change code on the Arduino at all.


73,
Dean
KK4DAS

Dean

will give the encoder software a try in the Pico version. Will let you know how it works. 

I get why Dr Lee pushed so much functionality off onto the Nextion. He was trying to squeeze as much as possible into that poor nano.

I am hoping that with the newer processors we can reduce the lioad on the Nextion making the maintenance of those screens much more doable (and perhaps supporting dumb lcds too). So will definetly take a look at how you did things in the future. 

73
Mark
AJ6CU

What's interesting is the Arduino mega was passed over
completely. With more IO and 250K of flash,more ram and
EEprom yet for work that otherwise fits the 8bit realm it
was passed.

Not knocking the 32bitters but they eat flash faster,
and Eeprom is likely external anyway.  The got used because
they were ubiquitous or cheap.  For DSP or dsp like work
they are a better for for the math needed.

The Nano Every, gets some of that at the cost of EEprom
but its easy to add externally if it were really needed.


Allison
------------------
Please use the forum, offline and private will go to bit bucket.