I’ve got an early Christmas present for you all! In conjunction with today’s final release of WSJT-X 2.0.0 (n.b. I’m not affiliated with that project in any way), I’m pleased to announce that I have now added the brand new 79-symbol FT8 protocol to my JTEncode Arduino library. The new version of the library is currently in testing and not available for upgrade in the Arduino Library Manager yet, so if you’d like to try it out, please download it from the development branch here and install it manually. After I’m confident that all is working well, I will release it to the main branch.
After having a lot of people asking me about it, last week I finally decided to take a crack at reverse engineering the FT8 protocol from the WSJT-X source code. I figured now was a good time since I’m in the final push to get OpenBeacon Mini out to production and a new version of the protocol was coming with the new v2.0.0 of WSJT-X. I had been awfully hesitant to tackle this in the past since all of the modulation algorithms are written in Fortran, a language that I do not know. There are no detailed technical descriptions of the protocol in plain English that I could find, so I would have to depend on reverse engineering the protocol solely from the code.
Armed with a F77 textbook I picked up at Goodwill and lots of Googling, I managed to make a big push over the last 5 days in order to give myself a Fortran crash course and learn how the algorithm works. With a ton of print debugging and by comparing the output of my code to the output of the official ft8code program from the WSJT-X package, I was able to nail it down.
If you are comfortable being on the leading edge of such things, please do give my library a try now and help me test it. It’s nice to see that the JTEncode library has been used in various ham projects out there, and at least once commercial product (other than the upcoming OpenBeacon Mini). I’m sure that the inclusion of FT8 will make it much more useful.
A quick proof-of-life update for you. The whole month of July was pretty much wiped out for me between the yearly family vacation which was followed by hosting friends from out of town. We had a lovely time, but it left very little time for getting work done. Add to that the fact that the GPU on my main workstation gave out, so I couldn’t really do anything on this PC until I acquired a new one (RX 560 4 GB to make this entire machine Team Red now). So given all of those circumstances, I didn’t really make any progress on OpenBeacon Mini. Apologies for that to my beta testers. Things will still be a bit slow while school is out here for summer break until late August, and then after that I expect to have my full allotment of work time again. Once school is back on, I should be able to do Twitch streaming again as well. Right now things are just too chaotic for that to happen on a regular schedule.
On a side note, I’m sure you seen me talking about using the Brave browser’s BATpublisher program to replace my old Patreon page. I completely understand that asking someone to switch browsers is a very hard ask, especially when the browser is still fairly early in development and needs more work in order to be highly polished. I recently learned of an extension for Firefox and Chrome that does the same function of distributing BAT to registered publishers that the Brave browser does, which should be a lot more tolerable for those who were considering the program but didn’t want to give up their current browser. The extension is called BATify, and it might be worth looking into if such things interest you.
It’s time for a brief update on how things are going with OpenBeacon Mini, the successor to the OpenBeacon MEPT that’s been a long time in the making. For those who are unfamiliar with the new project, allow me to give a very brief overview of its capabilities. The OpenBeacon Mini is an automated transmitter for amateur radio operators that allows for automated transmission of messages using propagation study modes such as WSPR and QRSS, along with many of the other JT modes and CW as well. The carrier is generated by a Si5351A clock generator IC which is fed with a TCXO reference clock for frequency stability. Low-pass filter plug-in band modules allow operation on any single band from 630 meters to 2 meters. The OpenBeacon Mini detects which band module is inserted and sets the frequency accordingly, making band changes as easy was swapping out a plug-in module. The power and a data connection is provided from a USB micro B connection to any PC. Accurate time synchronization is accomplished through this connection, as long as the PC has time set through NTP. The user interface is a 128 x 32 px OLED display and 7 pushbuttons. As always with Etherkit products, all firmware, hardware design files, and and software is open source. Extra pins from the microcontroller and extra clock ports from the Si5351 are broken out for use in experimentation and expansion.
Something like this project has been on the back burner for a long time, and is finally now able to see the light. I intend to launch this as a crowdfunded product at the same time as my Empyrean microcontroller, which is at the heart of the OpenBeacon Mini. The Empyrean is an Arduino Zero derivative in the form factor of small DIP module perfect for breadboarding. I’ll have more about this initiative to post on the blog in the near future.
My first beta tester, LA3PNA, recently received his OpenBeacon Mini and had a chance to put it on a NVIS antenna for a few hours on 60 and 20 meters. As you can see from below, he received plentiful WSPR spots in that short amount of on-the-air testing.
I have another early beta tester working on getting his OpenBeacon Mini on the air soon as well. I am looking at getting one more early beta tester going with this PCB spin, just so that I can be very sure that the next PCB spin will iron out all of the kinks. If you are familiar with MEPTs, using the Arduino environment to compile and load firmware, and don’t mind a little bit of firmware roughness, I’d love to have you on board. Send me an email to milldrum at gmail dot com to let me know you’re interested.
This weekend, I plan to get OpenBeacon Mini going on 6 meters in order to see how it performs there. It should be a perfect time, since it’s also the weekend for the ARRL VHF Contest. Keep an eye on my Twitter account and this blog for further updates on this project.
I know it’s been quiet on the blog front. It’s because I’ve been working through some tricky issues with OpenBeacon Mini firmware. A long story, but the gist of it is that a timer subtlety was causing some hard-to-troubleshoot problems causing inconsistent transmit timing for WSPR. I’ve finally overcome that particular family of bugs, and now have the transmit working reliably. As you can see, I’ve put OpenBeacon Mini on the air for the first time and it’s receiving spots. Now that I’ve confirmed that the basic functionality is working, I need to fill out a few more firmware features and then actual beta testing can start, which shouldn’t be very long now.
On another note, I’ve also been doing more PC and PC parts hustling on OfferUp in order to fund an upgrade to my main workstation. I managed to snag a Ryzen 5 1600 for a good price at $159 at Fry’s, since the new Ryzen refresh CPUs were just released. I’ve been using it for a few weeks now and it’s a fantastic processor. It also handles OBS much better than my old i3, so when I do get back into streaming on a more regular basis, my stream quality should be even better yet. From my testing, I should now be able to push out 1080p 60 FPS video to Twitch with no problem now.
Stay tuned, as the news around here should pick up again.
A brief update to let you know how things are going. I’ve got a long checklist of things to implement in the OpenBeacon Mini firmware, and much of it I can leverage from my old OpenBeacon 2 firmware (although quite a bit of that needs to be refactored and updated). However, one bit that I never implemented properly in OpenBeacon 2 was a menu system, so I decided to tackle that one first, since it will need to be written from scratch.
That’s what I’m working on at the moment. No Twitch stream for today, as I don’t think this would be very interesting to watch as I stumble around trying to figure out a good way to do this in C++. I’ve created a menu class, and I’m working out all of the details and debugging on the desktop PC, so that I can then transfer it to the Arduino environment once it seems to be working correctly. I think it should have that up and running by the end of the day, and that I’ll have another Twitch stream within a few days once I can get back to code that I’m a little more adept at writing.
Since I’m waiting for circuit boards for OpenBeacon Mini to arrive, I want to keep the waiting time as productive as possible, so I’ve been working on the firmware. Specifically, one of my recent goals was to factor all of the modulation code out of the spaghetti mess that is the current state of the OpenBeacon 2 firmware (which is my starting point for OpenBeacon Mini).
In that vein, today I managed to finish up work on release v1.0.0 of the Etherkit Morse Arduino library. The majority of the coding work was done during my last few Twitch livestreams, so other than tweaking and cleaning up the code, most of the work today consisted of creating documentation and getting the repository in shape to be a proper Arduino library.
The way that this library functions is quite simple. Since timing in Morse code sending is critical, the end user of the library is required to provide a function that calls the library’s update method every one millisecond. This type of interface was chosen so that the library can be platform agnostic (since Arduinos come with different microcontrollers which have totally different timer functions). An transmit output pin and speed in words per minute is specified when the class in instantiated, and then all you have to do is call the class’s send method to send Morse code on the digital output pin. Alternately, you can have your sketch poll the class’s tx variable and act on it accordingly. Pretty easy stuff.
I’ve put in a request for the library to be included in the official Arduino Library Manager, so if you want to give it a try, wait a day or so for it to be listed there. If you really can’t wait, there are instructions in the README about how to manually install it. Hopefully you find it useful, and as always, please file your bug reports and suggestions for improvements as an issue on GitHub. Thanks!
If you watched my previous Twitch stream, you may have seen that I completed the layout of the first PCB spin of OpenBeacon Mini. Today I ordered the PCBs from DirtyPCBs, along with boards for my low-pass filter module, and more Empyrean boards in anticipation of wider beta testing soon.
I wanted to get these boards to the fab before we started to run into the wall of Chinese New Year (which I seem to do nearly every year). I think I’ve ordered them plenty early, and even paid a bit extra for express shipping, so hopefully they’ll be in-hand around the beginning of February.
In the mean time, I’ll be working on some more coding for the OpenBeacon Mini on my Twitch stream and some other ancillary stuff while I’m waiting for the boards to arrive. Stay tuned for further news on this blog.
Thanks to the efforts of Etienne Scott, K7ATN, we who live in the Pacific Northwest have a couple of nice SOTA summit-to-summit activity days each year. One that happens in early spring and if I remember correctly the other which occurs later in the summer. I participated in the spring S2S Party two years ago, but haven’t had a SOTA activation since.
As mentioned in a previous post, things have been kind of crazy here lately, and Jennifer has been encouraging me to get out to do something I enjoy, so I decided to take this Saturday to participate in the S2S Party. I was considering Bald Peak, which is just on the outskirts of the Beaverton-Hillsboro area, and makes for a quick and easy trip, but by the time that I went to Sotawatch to claim it, I noticed that K7ATN had already done so. Thanks to SOTA Maps, I was able to easily browse some other peaks relatively close, and settled on Sheridan Peak, especially since a previous trip report tagged it as a fairly easy drive and hike.
I needed a travelling companion, so I asked my 5-year-old son Noah if he wanted to go, and he eagerly agreed. I wasn’t sure if that enthusiasm would hold up during the trip, but at least because of the short hike to the summit, it would be easy to bail out if necessary. So we departed the house at around 9 AM, stopped by McDonalds for a light breakfast and a large coffee for me, then took the backroads of Washington and Yamhill Counties out to Sheridan Peak.
The drive was uneventful, other than my phone’s GPS getting a bit lost at the very end of the trip. However, the driving directions from the two previous write-ups of this peak on pnwsota.org were great and got me right to the parking lot. Actually, the gate to the parking lot was closed, but that was OK because there is a nice big turnout on the road immediately below it, so we just parked there and walked around the closed gate.
The hike up to the summit was quite easy, and Noah did well for one of his first actual hikes. Unsurprisingly for a peak in the Oregon Coast Range, the weather was damp and showery. Although we didn’t have much of a view from the top due to the forest, one big advantage of that was the canopy over our heads providing a bit of a break from the rain.
Fortunately, I was prepared for the rain, and I quickly erected a tarp shelter for us to use to take cover from the elements. It was actually fairly cozy under the shelter, as another advantage of the tree cover was that it was acting as a nice wind break from the usual chilly blast you get on a peak.
I don’t currently own any HF portable gear, but thanks to the generosity of W8NF, I was able to borrow a Yaesu FT-817 and Elecraft T1 tuner. A few days prior to the activation, I cut a random wire and counterpoise that would at least work on 40 and 20 meters, and tested it in my backyard. That turned out to be a good thing, as I was able to get my wire in the tree and get the 817 QRV with no problems at all. I also brought along my Baofeng UV-5R with rubber duck/tiger tail combo for 2 meter FM ops, with the 817 as the designated backup if that didn’t work.
At the designated time of noon local, I heard K7ATN full quieting on 2 meters (which wasn’t a huge shock, as his peak was only about 20 miles away from mine). There wasn’t a huge turnout for this activity day like there was a few years ago when I did it on Cooper Mountain, but I did manage to make four S2S QSOs on 2 meter FM with the UV-5R in order to officially activate the peak. Woo! After that, I switched to 40 meters LSB on the 817 and made a couple of S2S QSOs with stations that I had already talked to on 2 meters and one with a local chaser. Finally, I had K7ATN spot me on 20 meters and managed to squeak out a couple more SSB QRP QSOs, both with stations in Arizona. By then, Noah was getting a bit cold and wanted to get going, but I was pretty happy with the results. From the sounds of things on 2 meters, a few of the other activators had some pretty crummy weather conditions to deal with, especially NS7P on Mary’s Peak.
So after about an hour on the peak, Noah and I packed everything up and headed back down the half mile or so to the pickup. I was very proud of Noah, as he did great for a 5-year-old; never really complaining and obviously really enjoying being out in nature, plus I think he liked the radio activity as well.
I’m really happy to have made this activation, especially since I was able to get Noah involved in both an activity out in nature plus radio fun! Thanks again to K7ATN for all of the hard work that you put into the PNW SOTA community and the rest of the activators for getting out there in this wet spring Oregon day. Stay tuned for hopefully one or two more SOTA activations this year, hopefully with more family members coming along on future trips.
