I have completed the task of putting the N6TV Keyer module into an Arduino library and have it merged in with the transceiver code base. It provides the following CW keyer modes:
- Curtis iambic A and B emulation
- Accukeyer emulation
- Smartkeyer emulation
- Bug mode
Autospace can be enabled optionally. Also supported is paddle swap. All the basics.
The first release transceiver feature set includes:
- Five 64 byte non-volatile editable message slots
- Easy CW speed adjust
- RIT On/Off
- Full break in CW
- Morse entered on the paddles in transmit is shown on the top line of the LCD display
- CW decoded from PSoC displayed in the same manner during receive. (This can be turned off if desired)
- VFO frequency display
- Relative signal strength display
- Power supply voltage display
I think that’s about it. Enough to efficiently run the radio with lots of room for additional features.
Reference and Design files are now updated and reposted.
I am updating all of the design files, some of the ones that had been posted are out of date.
Some of the files will not be available for download today, but will be back on line tonight.
A couple of years ago I exchanged some emails with avid contester Bob Wilson N6TV. He had one of my WKUSB keyer boxes and suggested that I add a particular keying emulation that he favored over others. WKUSB doesn’t support exact keyer emulations, instead it allows you to tailor the paddle sampling mechanism which gets you pretty close.
Anyhow, to help illustrate how this particular emulation worked he emailed me an entire keyer he had written in C for the PC platform many years ago. I was astonished at the complexity and detail of the module. Unfortunately I was not able to implement any of Bob’s algorithms in my keyer, It was impossible to translate it to PIC assembly in a way it would fit into the small code space I had available.
I archived the module and figured I would get back to it. One day when I was working on the C code for openQRP, I remembered the keyer module and wondered if it was possible to use it. It only took some minor modifications to get it to compile under Arduino and then a bit of interface tweaking to actually get it to work right. That’s the beauty of portable languages. It’s truly a great keyer and has a nice feel to it, maybe even better than my keyers.
I contacted Bob to ask him if I could get his permission to use his module in openQRP. The good news is he has consented and the keyer will be in the first beta release ! It really is a nice addition to the project. I am packaging it now as an Arduino library with a well documented interface.
Just a quick brief on libraries, Arduino supports the notion of object oriented programming which has many advantages. Essentially a software program is broken up into functional modules that are separate entities from the main program. Each object is written and worked on separately and “connected” to the main program at run time. In Arduino land, libraries are objects, I already have a library that manages the LCD display and soon there will be a keyer library. I would like to have a separate libraries for CW message management, configuration storage, and many other things.
More importantly, the only reasonable way to foster multiple contributors to openQRP firmware is through the use of libraries which can be worked on separately and then brought into the main code base for integration and debug.
Another nice plus of objects is that if someone doesn’t like the keyer or the way the display works, they can write their own version and replace it. To try to do that in a non-object oriented software project is very difficult. Objects generally have a long life, they can be transported to new platforms and applications.
So that’s it for today, back to the lab.
I ask myself this question every day and a series of critical emails I have received lately encouraged me to write this post. I know folks are anxious to see something happen to prove this is not just an idea without fruit.
I formally started this project in December 2008. At that time I had a working prototype, most of the parts for 100 kits were in house, and it was all coming together nicely. In March 2009 I was on my way to work when I got tail ended by a truck going 65 MPH. My car was totalled and I was out of work for 2 months. I got hurt pretty bad and openQRP had to take a back burner for a while.
I have been playing catch up ever since and with a family (wife and two young children), full time job, a keyer kit business, and a Mom with dementia, my life has been chock full of stuff. I’m no different than anyone else, and I’m certainly not complaining, I’m blessed in so many ways.
I am trying to funnel as much time as I can to get the beta kits shipped, I really underestimated how long it would take to get everything done and I humbly apologize for that, I’m just not as fast as I used to be. It’s really analogous to priming a pump. Once the kits are out, firmware development can kick into high gear, and work on the assembly manual can get started. (You will be very surprised to hear who has expressed interest in working on the manual !) There are some other surprises as well. The main reason I decided to continue this project was the fact that it could be a community effort and I would not have to do it all myself.
So the project is very much alive, it’s a labor of love, it will all be good !
73 Steve K1EL
There has been a large amount of interest in the group in the past couple of days.
I have successfully created a custom openQRP object for Arduino 18. It took quite a while since the process is not documented and I had to figure it out by trial and error. As with most of my work with Arduino the fastest way to make progress is to find some examples and learn from them. It’s a very modular setup now, one folder with all of the related openQRP files in one spot. There is no longer any need to hack any of the standard Arduino distribution files. Even better, when new versions of Arduino are released all need happen is update a file pointer to the openQRP directory. Very nice addition to the Arduino IDE.
So I am just finishing up a base firmware release to get folks going and then add more functions as we get going.
I will be sending out emails next week to all those who expressed interest in being beta builders and depending on response we’ll see how many extra kits I have to distribute beyond that.
73
Steve K1EL
I am in the process of updating the CPU control firmware for the first release, I want to ship the beta kits with enough functionality to be able to run all of the features of the radio “out of the box”. I expect folks will have updates and improvements as we go forward.
Anyhow, in the process of getting things ready I want to move to release 18 of the Arduino toolset. The main reason for this is that the notion of 3rd party platforms is now supported. What this means is that I can build a custom environment for the openQRP CPU which is self contained and separate from the general Arduino release. In future when upgrading to newer Arduino releases, the openQRP specific files will not be affected. It has taken some time to figure out how it all works, but worth the effort since new openQRP code distributions will simply be one directory that includes all libraries, customized core files and header files. So to upgrade to a new openQRP version will just require the replacement of this one directory.
Considering all of the ups and downs over the past year, it’s amazing that I am finally to the point of having beta kits ready to ship. On the other hand, it will be even more amazing if there is anyone left who hasn’t given up on the whole thing and moved on.
So, in the interest of helping me figure out how many beta kits to ship, please drop me an email if you would like to participate in the beta kit build. I plan to email all those who have already “raised their hand” and I will not remove anyone from the list until I have gotten an ok to do so.
Thanks, Steve
On the home stretch now, I have the today off from work so we’ll be kitting the two receiver sections, with some help from my daughter (9 yrs old)
Remaining tasks:
1) Package LCD display section and PSoC/AF Amp section.
2) Program Arduino CPUs & PSoCs, Package ICs
3) Package mechanical parts (knobs, heatsink bracket, screws)
4) Package controls/connectors (RIT, RF gain, 10 turn tuning pot, BNC)
5) Measure out copper wire for toroids
6) Box ‘em up
73 Steve
I am currently about halfway through matching crystals for the Rx Filter and Tx Mixer, it is going much easier than I thought it would. The crystals I have are very high quality and are very close in frequency. I did 14 sets last night and will do 14 more tonight.
Lots of progress has been made in kitting, all that is left is the receiver. I have been kitting the transceiver in sections, three or four sections per plastic bag. This will make assembly easier since each section is a self contained portion that can be tested after installation. For example, the first section is power supplies followed by the CPU section. Next is the VFO followed by the output filter and Rx/Tx antenna switch. From there on to the receiver and transmitter sections. This method makes kitting easier as well since there are only a handful of parts per section are easier to count and check.
Good news today, Digikey now has ATmega168 CPUs back in stock, this is the last part I need to order. For some reason these are difficult to find right now, maybe Arduino builders are buying them all ! Mouser has been out of stock for months and are still looking at 13 weeks before they get more.