Inner Circle Newsletter December 2024

Welcome to Open Research Institute’s Inner Circle Newsletter for December 2024. We have a lot to share with you!

Open Research Institute is a non-profit dedicated to open source digital radio work. We do both technical and regulatory work. Our designs are intended for both space and terrestrial deployment. We’re all volunteer. You can get involved by visiting https://openresearch.institute/getting-started

Membership is free. All work is published to the general public at no cost. Our work can be reviewed and designs downloaded at https://github.com/OpenResearchInstitute

We equally value ethical behavior and over-the-air demonstrations of innovative and relevant open source solutions. We offer remotely accessible lab benches for microwave band radio hardware and software development. We host meetups and events at least once a week. Members come from around the world.

Read on for regulatory, technical, and social articles. We close with a calendar of recent and upcoming events.

Want to subscribe to the Inner Circle? Sign up at http://eepurl.com/h_hYzL

Previous issues of Inner Circle can be found at https://www.openresearch.institute/newsletter-subscription/

Regulatory Work at ORI

Making Open Source Easier for Everyone

Past regulatory work at ORI can be found at https://github.com/OpenResearchInstitute/documents/tree/master/Regulatory

219 MHz Project

by Mike McGinty

Federal Communications Commission License DB (FCC LicDB) is a set of tools for exploring the FCC license database dumps. The tools are at https://github.com/tarxvftech/fcc_licdb

These database dumps are at https://www.fcc.gov/wireless/data

What you see in FCC LicDB is a way to download and then import most of the weekly database dumps to an sqlite database. Expect a couple gigabytes for uls.db, depending on how many services you import.

After that, the purpose of this repository gets more esoteric because it’s less about exploring and more about answering. (Answering what?)

There’s a problem with the 219-220 MHz amateur band. 47 CFR part 80 defines this band (among others) as for Automated Maritime Telecommunications Systems (AMTS), but that idea completely failed and so now there are no AMTS stations, just companies licensed for AMTS, usually through leases, that use the spectrum for other purposes.

The restrictions on Amateur secondary use of the band defined in part 97 were designed for a world where AMTS stations were on the coast. This, along with other circumstance, define the problem that exists today – it is nearly impossible to operate an Amateur radio on the band despite hams deliberately being given the spectrum.

See https://github.com/tarxvftech/47CFR for more details on this situation. I started this LicDB repo to figure out where these AMTS licensees operate, and what they are using it for. The ULS database interfaces available to the public are not sufficient for answering questions like this (details in W5NYV’s first talk “The Haunted Band”).

But where a generic system may struggle, a more targeted approach can solve.

What you see below is a functionality-first view of the FCC licensing system mapping as much of the AMTS stations licensed or operating in the 219-220MHz band as can be found in the database.

It’s not perfect – working on data from other people and systems that you have no control over never is – but it’s much better than all existing alternatives.

Other Projects

It’s expected this would be useful for redoing W5NYV’s exploration into the demographics of Amateur Radio operators in the US: https://github.com/Abraxas3d/Demographics

Similarly, it might be very interesting to plot ALL the LO, PC, and other entries, and then merge in the other data that isn’t in the FCC database, like ham radio repeaters, to try to make the radio services in the ether around you that much more legible.

Some entries are not easy to import into the database, or have data errors that make them difficult to plot on the map. Those entities are not presently accounted for.

Above, AMTS stations in the United States. Below, a few detail images from the map, which can be found at https://amts.rf.band (heavy data, be patient for first load).

An article from ORI called “Space Frequency Block Coding Design for the Neptune Communications Project” will be in the January-February 2025 issue of QEX Magazine, from ARRL. Thank you to ARRL for publishing open source work from ORI.

Article Summary

The article discusses the design and implementation of Space Frequency Block Coding (SFBC) in the Neptune Communications Project, a digital radio initiative operating at 5 GHz for amateur radio applications.


Key Concepts and Objectives:

SFBC is a technique used in digital communications to improve signal resiliency by leveraging spatial, frequency, and coding diversity. It is commonly implemented in systems using Orthogonal Frequency Division Multiplexing (OFDM), utilizing multiple antennas for diversity. The mathematics are explained step-by-step with diagrams and equations. Noise calculations worked out in an Appendix.


Amateur Radio Application:

The Neptune project focuses on transmitting robust digital signals in noisy environments, essential for drone and aerospace communications. SFBC increases the likelihood of data recovery by mitigating multi-path interference and improving signal-to-noise ratio (SNR). An open source OFDM modem is needed in amateur radio.


Technical Details


Implementation:

SFBC transforms transmitted signal samples mathematically before sending them via two transmit antennas. Multi-path and spatial diversity enhance signal integrity against environmental reflections and interference.


Operation:

Signals are transmitted using OFDM, where subcarriers provide frequency diversity. The encoding does not increase throughput on its own but makes it easier to achieve maximum throughput performance.


Coding techniques like the Alamouti scheme are explained, with diagrams, for creating and decoding signals.


Trade-offs:

SFBC reduces SNR by 3 dB compared to optimal techniques like Maximum Ratio Combining but avoids the need for channel state knowledge at the transmitter.


Practical Implementation:
SFBC was modeled and tested in MATLAB/Simulink, with plans for FPGA and ASIC implementations.


Future work includes:

Expanding to Space Time Block Coding (STBC).

Live demonstrations of SFBC/STBC performance differences.

Open-source release of HDL source code for hardware implementations.


Call to Action:

The Neptune project is a volunteer-driven, open-source initiative under the Open Research Institute (ORI). Community participation is encouraged, providing educational and developmental opportunities in digital communication technologies.

Watch Dr. Marks explain the RFBitBanger project and the SCAMP protocol in this video at https://www.youtube.com/watch?v=Fbgs_4QsKnE

And then… let us tell you that SCAMP is now in FLDigi!

SCAMP is now even easier to use. If you want to get involved with this new mode and also build your skills with a very special low power HF radio kit, please visit our eBay listing for kits at https://www.ebay.com/itm/364783754396

A Tale of Troubleshooting

Problem Solving our Minimum Shift Keying Implementation in the Lab
by Team OPV

Minimum shift keying (MSK) is the modulation used by Opulent Voice, our open source uplink protocol for our space and terrestrial transceiver. Unlike some other modulations, there aren’t a lot of documented and working examples of MSK, despite the many advantages of using this modulation for space and terrestrial channels. One of our educational goals at ORI is to provide exactly that, a documented and working example of MSK, that also delivers useful functionality to the amateur radio satellite service. 

In the process of writing down a description of what happens mathematically, so that software defined radios like the PLUTO SDR can transmit and receive our Opulent Voice protocol, there’s been quite a few troubleshooting sessions. One session solved a problem where the main lobe bandwidth was too large. Another session solved a problem where the processor side code didn’t properly configure the radio chip. Another session switched to the correct version of LibIIO, or Library of Industrial Input and Ouput routines. The wrong library meant that the radio was “sort of” working, but not completely. 

Troubleshooting and debugging systems is where most volunteer engineering time is spent. This is no different from professional development, where blank-paper time spent writing down routines may be a small fraction of the total development time of a project.

It can take multiple attempts to solve a problem. When this happens, it’s important to back up completely and recheck basic assumptions. Looking at the images below, one can see the desired MSK spectrum at the top. On the bottom is an example of an undesirable spectrum. The main lobe is bifurcated and the sidelobes have extra power. If you look at the graph, you can see that the sidelobes are higher in the “bad” example than they are in the “good” example. These are all clues, and there are several ways to go about attempting to solve the problem. The bad or “split” spectrum seemed to show up at random times, but it would go away when new PI controller gain pairs were written to the radio. 

Why were we writing new proportional and integral gains to the radio? We were trying to tune our PI Filter, which is in the Costas Loop, which is in charge of tracking the frequency and phase of our signal so we can demodulate and decode successfully. We wrote code to search through proportional and integral gain pairs, testing their performance both in digital loopback and in loopback over the air.

After reviewing the code, asking for help, getting a variety of good advice, and trying to duplicate the problem in MATLAB, the problem unexpectedly went away when the processor side code was updated to remove extra writes to MSK block configuration registers.

The lessons learned?

* Clean code that matches the design of the hardware may prevent unexpected behavior. Don’t be sloppy with your test code!

* Keep up to date on changes in register accesses and behavior. There was a change from setting and clearing a bit in a register to the bit being toggled. This was a change from the level being important to the change in the level being important. Do your best to match what’s in the hardware! 

Below, the “bad” spectrum as observed in the lab.

Below, the “good” spectrum, which returned after what we thought were unrelated code changes.

Opulent Voice at University of Puerto Rico

An Educational Success Story

by Michelle Thompson W5NYV with Oscar Resto KP4RF

Oscar Resto is an Instrumentation Specialist at the University of Puerto Rico’s Department of Physics. He also serves as the Principal Investigator for the university’s RockSat-X program. RockSat-X is a highly-regarded and very successful educational program sponsored by NASA and the Colorado Space Grant Consortium at the University of Colorado at Boulder. RockSat-X offers university and community college teams the opportunity to develop experiments for suborbital rocket flights, fostering innovation and practical experience in space-related fields.

Beyond his academic roles, Oscar is active in the amateur radio community, holding the call sign KP4RF. He has been involved in initiatives such as renewing the Memorandum of Understanding between the ARRL Puerto Rico Section and the American Red Cross Puerto Rico Chapter and has presented to a wide variety of audiences about amateur radio and emergency communications during and after major hurricanes. 


The University of Puerto Rico has actively participated in NASA’s RockSat-X program since 2011, providing students with hands-on experience in designing, fabricating, testing, and conducting experiments for spaceflight. UPR’s RockSat-X team has developed increasingly complex experiments over the years. In 2011, UPR’s inaugural RockSat-X project utilized mass spectrometry to analyze atmospheric particles and pressure. Subsequent payloads have continued to evolve and refine the investigation of the “middle atmosphere”, an often-overlooked layer in atmospheric studies. 

Oscar’s engineering design philosophy is to put the program in the hands of the students. The students are fully involved from the beginning of the process until launch. Oscar supports and enables consistent student success in two ways. First, by using the Socratic method of asking questions to lead the students through the many stages of design, test, documentation, and build. Second, by communicating clear expecatations about process and deadlines. Students source parts, build components using a wide range of manufacturing processes, and program all of the control and embedded devices. They carry out testing at the component, module, and end-to-end systems level. The student interface with NASA through meetings and regular reports.  


Recent missions included deploying sterilized collection systems into the space environment to gather organic molecules, such as amino acids, proteins, and DNA, from altitudes between 43 to 100 miles above Earth. To ensure the integrity of collected samples, the team implemented innovative decontamination procedures that were carried out in flight.

For the 2023 and 2024 UPR RockSat-X entry, Opulent Voice was included as a communications payload. That version was a 4-ary FSK modulation, voice only, and ran on a general-purpose processor. In 2023, the rocket experienced a failure. In 2024, the mission was a complete success, with Opulent Voice received on a student-built and crewed portable station near the launch site. For 2025, assuming UPR’s RockSat-X application is accepted by NASA, the Minimum Shift Key (MSK) version of Opulent Voice, implemented on an FPGA and deployed on a PLUTO SDR, will be used by the student build team. This MSK version is much more advanced and more spectrally efficient.

Review the MSK version at https://github.com/OpenResearchInstitute/pluto_msk
See an image of the student poster presentation about the 2024 UPR RockSat-X project below. 

Shipment was delayed, but a nice surprise for Ribbit has finally arrived. Below is the plaque for Ribbit’s 2023 Technical Innovation Award.

The metal surface has black lettering and an image of a laptop computer. The body of the plaque is a handsome hardwood.

The text reads “For developing the Ribbit app for Android and iOS devices. The innovative and open-source Ribbit app allows amateurs to utilize audio from amateur radio transceivers such as VHF/UHF handhelds to send and receive text messages across the devices. The Ribbit app leverages OFDM technology currently used in cellular 4G and 5G networks & WiFi.”

Below, the plaque hanging on the wall in Remote Lab West.

Remote Labs are test benches with spectrum analyzers, oscilloscopes, power and frequency meters, FPGA development stations, power supplies, and multiple SDRs. The equipment is supported by a computer running virtual machines with a variety of operating systems to support software, firmware, and hardware development. Remote Labs are available 24 hours a day, 365 days a year for open source development. 

Thank you to Pierre and Ahmet for all the extremely hard work to make Ribbit so successful!

Learn more about Ribbit and try out the web app at https://www.ribbitradio.org

Geometry Puzzle

Given a 3, 4, 5 right triangle, with an inscribed semi-circle, where the hypotenuse of the triangle bisects the circle to form this semi-circle, find the area of this semi-circle.

Spoiler! The worked-out solution by Paul Williamson KB5MU is below.  

The Inner Circle Sphere of Activity

December 17-22 2024 – Open Research Institute participates on the Federal Communication Commission’s Technological Advisory Council (TAC). Working groups composed of volunteers from industry, academia, and open source (ORI) meet weekly and debate and deliver advice to the FCC quarterly. This hybrid meeting is streamed on the FCC website. 

December 31, 2024 – Fiscal year ends for Open Research Institute. Work begins on filing 2024 IRS 990 returns, which are due May 15, 2025.

December 20, 2024 through January 6, 2025 – Holiday Break for all labs and teams. 

March 6, 2025 – Open Research Institute celebrates another birthday with parties planned so far in the US, Canada, and Europe. Sign up for a fun day commemorating open source volunteers around the world by writing hello@openresearch.institute.

Thank you to all who support our work! We certainly couldn’t do it without you. 

Anshul Makkar, Director ORI
Frank Brickle, Director ORI
Keith Wheeler, Secretary ORI
Steve Conklin, CFO ORI
Michelle Thompson, CEO ORI
Matthew Wishek, Director ORI

Inner Circle Newsletter: Autumn 2024

A Harvest of Regulatory and Technical Updates

Open Research Institute is a non-profit dedicated to open source digital radio work. We do both technical and regulatory work. Our designs are intended for both space and terrestrial deployment. We’re all volunteer. You can get involved by visiting https://openresearch.institute/getting-started

Membership is free. All work is published to the general public at no cost. Our work can be reviewed and designs downloaded at https://github.com/OpenResearchInstitute

We equally value ethical behavior and over-the-air demonstrations of innovative and relevant open source solutions. We offer remotely accessible lab benches for microwave band radio hardware and software development. We host meetups and events at least once a week. Members come from around the world.

Subscribe to this newsletter at http://eepurl.com/h_hYzL

Ribbit Radio Update

It isn’t often that a completely new way of using existing technology in a truly innovative way on the amateur bands excites the community, but Ribbit consistently delivers.

What is Ribbit?

Ribbit is a novel digital text messaging mode for VHF/UHF communications for recreational and emergency use. It radically increases the density of information transmitted by spectrum used. Ribbit turns text into encoded audio, which can be played from your smartphone into the microphone of any radio, on any band, under even very noisy conditions. A smartphone with the Ribbit application on the other side can recover this message. Your information will get through.

Ribbit leverages the computing power of the modern smartphone to increase the capabilities of any Handy Talkie without requiring any additional hardware or cable.
Its redundant distributed nature allows it to function even when internet connectivity is lost during emergencies or just not available due to poor coverage.

Developer Updates

Project Lead Pierre W4CKX and Rattlegram Developer Ahmet Inan supported a transition of project development to Alex Okita KO6BVA in late 2023. Since then, Alex has made several big strides forward in both development and demonstration.

Alex’s most recent TO DO list included the following tasks.

1) Building a scheme to compact the header for Ribbit. The header is a bit long and could be shortened to save some bits using a raw bit stream of a simplified character map.

2) Add a keyEncoder to Code Witches as the keyboard input gets letters added. When the “Enter” key is pressed begin encoding/consuming the characters in the input area.

3) May also want to add in a sort of message queue above the input area.

4) Build a useful CW-Font for code witches and anything else anyone wants to use it for.

All of this work enabled a highly successful demonstration of Ribbit at DEFCON 32 in Las Vegas, Nevada, in mid-August 2024. A special thank you to RF Village for hosting ORI’s Open Source Showcase.

Visitors to the exhibit were able to see Ribbit work in a busy and noisy environment. DEFCON, like most other very large conferences, is acoustically noisy, but also very electrically noisy. Ribbit was demonstrated all weekend long in a very harsh environment, as the WiFi Capture the Flag competition was happening literally steps away from the Ribbit demonstration. The venue, Las Vegas Convention Center West, was full of conference attendees. Despite the background noise and substantial RF interference, Ribbit worked from Smartphone app speaker output, to Family Radio Service microphone input, over the air on a busy FRS channel, to the receiving FRS radio speaker output, to a Ribbit application microphone input on the monitoring smartphone. Being able to transmit and reliably receive accurate text data is a notable achievement.

Alex has integrated the Ribbit functionality into a web application. This makes Ribbit even easier to use than traditional native applications. The live web app demonstration can be found at https://badkangaroo.github.io/

Recordings of presentations about Ribbit, along with posters and diagrams, can be found at https://www.ribbitradio.org

The source code can be found at https://github.com/OpenResearchInstitute/ribbit_webapp

Practical Real World Use

The technical demonstration for Ribbit, called Rattlegram, got very positive reviews for utility in the field from Chile and Argentina mountain rescue groups. The challenge is supporting hikers and skiiers in places where cellular coverage is limited or not available. Ribbit functionality provided clear benefits with no downsides.

Carlos, our contact in Argentina who supports mountain rescue operations, described his experiences using Ribbit technology.

“Hi everyone, how are you? I’m just back from the mountains in Chile. We did some testing with Rattlegram, in very windy conditions (without any cables) and worked just great !
Send you a picture & video of one of the test we made. We were at this summit:”

In Argentina, Carlos reported:

“These past few months, we have been going out to the mountains, and been using Rattlegram with lot of success. In one of the ‘refugio’ we left an old cell phone with Rattlegram loaded besides the base radio, and we have been sending messages in all the backcountry ski outings and all the messages arrived without a problem.”

If Ribbit can work on the top of the mountains in Chile and Argentina, and if it also performs really well in noisy urban environments, then what can’t it do?

Ribbit Can’t Flourish Without Your Support

Ribbit is innovative, useful, and fully supported by Open Research Institute. But, it won’t realize its full potential without continuing development and community support. If you are excited about Ribbit and want to help, please join ORI at https://openresearch.institute/getting-started and let us know you want to get involved with Ribbit. We’ll make sure you get on the mailing lists and Slack channels.

ORI graciously accept donations for Ribbit development. Ribbit has a dedicated bank account, follows non-profit best practices, has an enforced code of conduct, and regularly reports to ORI leadership.

Thank you to everyone helping make Ribbit successful, useful, exciting, and fun to use!

Opulent Voice Comes to the PLUTO SDR
An Open Source Minimum Shift Keying Implementation

Opulent Voice is the native digital voice and data protocol for ORI’s open source satellite (or terrestrial) system called Haifuraiya. With high fidelity voice quality, seamless integration of data, keyboard chat, and authentication and control messages, amateur operators experience something truly new and enjoyable. As described by ORI Director Steve Conklin AI4QR, “Leave scratchy and harsh proprietary vocoders with clunky or incomplete data mode integration behind for good.” All source code at https://github.com/OpenResearchInstitute/pluto_msk

Things worth doing are rarely easy. The Minimum Shift Keying (MSK) implementation of Opulent Voice (OPV) on the PLUTO SDR is no exception. Challenges to the documentation, design, implementation, and test cycles have come up throughout the process. The response from the open source digital radio community has been solid, inspiring, and productive, with patient problem-solving winning the day every time.

Michelle Thompson, ORI’s CEO, described her perspective on OPV’s progress recently at an IEEE event, stating:

“I would like to thank everyone helping ORI achieve ambitious goals for our uplink protocol. It’s a real pleasure to serve this community and meet the needs of this project. It’s a privilege to be part of something so innovative and relevant.”

This feeling is reflected by the OPV volunteer team, who are actively involved around the world in promoting open source work and helping ORI projects like OPV succeed.

Successes Over the Past Quarter and Current Status

OPV was the communications downlink for a NASA RockSat-X mission executed by the University of Puerto Rico, one of the most consistent and successful teams participating in this competitive program. The mid-August 2024 launch from Wallops went flawlessly. The performance of OPV met all expectations and data recovered from the launch is being used to further develop and improve the communications protocol.

OPV presentations at HamCon:Zion and DEFCON during the summer of 2024 were extremely well received, giving positive educational value to the community. Amateur Radio deserves quality digital communications. OPV delivers excellent results and is well-documented.

There is still a long way to go. The physical layer work is currently focused on tuning the tracking loops in the demodulator. Once the physical layer is reliable, then the functions that integrate voice, data, keyboard, and channel control messages will be integrated into the PLUTO SDR build and tested. Application layer functions in HTML 5 have a head start, with some tests already completed. Parallel integration efforts from F5OEO and OpenCPI, both of which will expand the number of hardware platforms that OPV can use, are well underway.

Below, an example of bit-accurate simulation results for OPV, with signal names on the left and waveform values on the right.

Below, the spectrum of OPV, showing main lobe null-to-null span of 81 kHz, and signal sidelobes.

Haifuraiya and Modem Module Update

The work on Haifuraiya has broader appeal than just as a HEO/GEO satellite design. The “modem module” approach, developed by Matthew NB0X, is summarized at left.

At left is the most recent high level block diagram.

Haifuraiya – Open Source HEO/GEO Amateur Satellite Update

The multirate channelizer has been implemented in Remote Labs West on the zc706/ADRV9009 station. At left is a summary of the channel plan for the satellite receiver.

Regulatory Work at ORI
Making Open Source Easier for Everyone

Past regulatory work at ORI can be found at
https://github.com/OpenResearchInstitute/documents/Regulatory

A special Halloween season workshop about exorcising the Haunted Band of 219-220 MHz was held by IEEE and ORI on 29 October 2024.

The Zoom meetup was well attended with the majority of RSVPs participating on the call. The meeting was recorded for those that couldn’t make it. The video recording of the background session, followed immediately by the workshop, can be found at https://youtu.be/wGX__qcFrT4

219 MHz is a secondary allocation for amateur radio. It has excellent channel characteristics, is open to fixed point-to-point digital links only, allows 100 kHz bandwidths, has a minimum of 56 kbps data rates, and has had no activity for decades. It’s time to take this band back!

Why is there no activity? We believe this band is inactive because of the notification requirements in FCC part 97 and part 80. We assert that these notification requirements, which pull ARRL into the loop from two different directions, are impossible for both amateurs and commercial licensees to comply with.

What are these notification requirements? If you as an amateur want to operate on 219 MHz, you have to determine if there’s an Automated Maritime Telecommunications System (AMTS) station within 80 km of your amateur station. You then have to ask permission from the AMTS station(s) in order to legally operate with at least 30 days notice. If you are between 80 km and 640 km, then you have to notify the AMTS stations at least 30 days in advance of activating the band.

A publicly accessible database of amateur and AMTS stations on 219 MHz is supposed to be maintained by ARRL. This is a rule in Part 97 (for the amateur radio stations) and in Part 80 (for AMTS stations). This database does not appear to exist.

AMTS stations did not report their information to ARRL. Requests to ARRL for a copy of AMTS stations have not been answered. Requests for a copy of amateur radio stations that have notified the ARRL of intent to operate have also not been answered.

These requests were made by multiple amateur radio operators in the October – December 2023 time frame. This was before the cyberattack in 2024, which did sideline a lot of ARRL’s services and activities.

The 219 MHz band regulations need a serious overhaul. We believe a proposal for new rules for this band are a necessary step towards restoring amateur use of this band. We believe that rules can be proposed that will both promote modern and innovative digital activity, and at the same time, not endanger the primary licensees in any way. While the AMTS service no longer exists as originally envisioned, the AMTS licenses have been leased out to fundamentally different services, such as railroads. These primary licensees can share the band with amateur radio in, at the very worst, a mutually inoffensive way and, at the very best, a mutually beneficial manner. It’s up to us to make this better future happen.

In order to make an effective proposal to the US FCC for updated rules for this band, there are things that we need to sort out. We need to know what we want and we need to know what the primary users want. We need to anticipate and answer objections to dropping the onerous notification requirements, and we need to clearly state the value that an amateur radio allocation on this band brings to education, public service, citizenship, and technical advancement of the radio arts.

The workshop on 29 October was the first strong step towards sorting out a draft of proposed rulemaking for restoring amateur radio service use of the 219 MHz band.

Discussion during the workshop resulted in an outline for a draft rulemaking proposal. ORI sincerely thanks everyone that participated during the event and through email correspondence.

Draft Outline

1) Demonstrate that the current rules are not working. State our case that the notification requirements are impossible to comply with and are the reason that there is no activity on this band.

2) Cite 60m as an example of successful similar activity.

3) Assert, providing evidence, that amateur radio operators already know how to share spectrum with other services. We already know how to not cause problems for the services that we share spectrum allocations with. We do not need additional notification requirements or to sign declarations to the ARRL in order to be able to successfully operate on an amateur radio band as a secondary user.

4) Show, from a ULS database perspective, the current utilization of 219-220 MHz. Amateur activity does not threaten primary licensees.

5) Show, to the best of our ability, the actual use of 219 – 220 MHz. This will require a call for participation for sensing stations, such as WebSDRs, amateur operators, receiver enthusiasts, and distributed receiver networks such as SatNOGS, to monitor 219-220 MHz for some period of time, in order to measure primary licensee activity on the band.

5) We assert that AMTS no longer exists. The current primary licensees are not coastal stations. The rules assuming coastal activity do not reflect the reality of this allocation as it exists today. Old rules are hampering efficient use of the spectrum.

6) Propose specific deletions of rules. What exactly should and could be struck down?

7) What are the anticipated effects, repercussions, both positive and negative, of deleting the notification requirements.

8) Is there anything else that could or should be changed? We discussed the 100 kHz bandwidth requirement and it’s origins in specific equipment available to amateurs at the time. Current FCC thinking is to not have rules that hardcode in equipment requirements. Deleting the 100 kHz bandwidth limit in favor of no bandwidth or symbol rate limit had broad support at the workshop.

Thank you to all of you that support our regulatory work. It will take a lot of time and effort to draft proposed rules and to go through the proposal process. The FCC may or may not choose to entertain new rules for 219 MHz. If they do, then a public comment period will happen. If they do not, then the draft rules will still be of benefit, as they will record the point of view and consensus of digital mode amateur radio experimenters and enthusiasts.

Please join this effort at ORI by visiting https://openresearch.institute/getting-started

Sphere of Activity

July 12-13 2024 – ORI exhibited at HamCon:Zion in St. George, Utah, USA. We invited Deep Space Exploration Society (DSES) and QRZ.com columnist Dave Jensen to join our booth. We showcased their work alongside our technical and regulatory acheivements. Total staff was three for this weekend event at a very nice conference center. Some of the travel expenses were reimbursed by ORI. This collaboration was entirely successful. Our CEO gave a talk about AI/ML in Amateur Radio at HamCon’s forum, which can be seen at https://www.youtube.com/watch?v=ZgHUavf5Ddo

August 8-11 2024 – Our Open Source Digital Radio exhibit at DEFCON 32 in Las Vegas, Nevada USA was a big success. ORI hosted demonstrations from RFBitBanger, Ribbit, Opulent Voice, and our Regulatory team in the RF Village. A staff of four set up, staffed, and tore down the exhbit. Travel and lodging was funded by ORI. Our CEO gave an RF Village talk about Synthetic Aperture Radar and Amateur Radio, which can be seen at https://www.youtube.com/watch?v=fiR4woe4O5Q

August 29 2024 – ORI participated in the quarterly Federal Communications Commission Technology Advisory Council meeting and presentation in Washington, DC. ORI is represented on the FCC TAC by Michelle Thomposn and Matthew Wishek. Open Source and Amateur Radio interests have been defended at the federal level. ORI Contributions to the Dynamic Spectrum Sharing and 6G Working Groups can be seen in the video at https://www.fcc.gov/news-events/events/2024/08/technological-advisory-council-meeting-august-29-2024 If you are interested in supporting regulatory participation and defense, please join ORI, support ORI’s work, and let us know how you want to help.

October 2-9 2024 – ORI organized a week-long event called Digital Update for Microwave (DUM) in Vancouver, British Columbia, Canada. There were 3 on site for this event and 9 participants virtually. Housing was reimbursed by ORI. The focus of the workshop was Opulent Voice and Iterative Receiver Theory technical work. We did not address the 10 GHz antenna questions posed from our outreach prior to the event due to time limitations. Better 10 GHz mobile radio gear is what people are looking for, and this will get attention from ORI over the next quarter. DUM is an event that provides opportunities for people interested in digital communications on the amateur microwave frequencies. The contributions to ORI’s GitHub repositories showed that DUM was well worth the effort. Should ORI have a DUMII?

Thank you to all who support our work! We certainly couldn’t do it without you.

Anshul Makkar, Director ORI
Frank Brickle, Director ORI
Keith Wheeler, Secretary ORI
Steve Conklin, CFO ORI
Michelle Thompson, CEO ORI

Inner Circle Newsletter: Summer 2024

A Sizzling Summer Summary prepared just for you!

Read on for highlights from all our technical and regulatory open source digital radio work. ORI’s work directly benefits amateur radio, provides educational and professional development opportunities for people all over the world, and puts ethics and good governance first.

Opulent Voice Flying High

Opulent Voice is an open source high bitrate digital voice (and data) protocol. It’s what we are using for our native digital uplink protocol for ORI’s broadband microwave digital satellite transponder project. Opulent Voice has excellent voice quality, putting it in a completely different category than low bitrate digital communications products such as D-Star, Yaesu System Fusion, and DMR.

Opulent voice switches between high resolution voice and data without requiring the operator to switch to a separate packet mode. Opulent voice also handles keyboard chat and digital file transmission. Seamless integration of different data types, using modern digital communication techniques, differentiates Opulent Voice from any other amateur radio protocol.

Opulent Voice will fly on the University of Puerto Rico’s RockSat-X launch on 13 August 2024. It’s been a very positive experience working with the students and faculty at the University.

An implementation on FPGA for the PLUTO SDR is well underway, with a active international team delivering quality results. This implementation will not only turn your PLUTO SDR into an Opulent Voice transceiver, but it will have remote operation functionality.

Hear what Opulent Voice sounds like by following the links in an earlier update at https://www.openresearch.institute/2022/07/30/opulent-voice-digital-voice-and-data-protocol-update/

We’ve come quite a long way in less than two years! The FPGA implementation upgrades the modulation from 4-ary frequency shift keying to minimum shift keying, and increases forward error correction performance and flexibility.

HAMCON:ZION 2024 is This Week!

Please visit us at HAMCON:ZION 2024 this weekend, 12-13 July 2024 in St. George, Utah, USA.

The event website is https://www.hamconzion.com/

ORI will have a club booth at the event. We opened our space to QRZ.com (https://www.qrz.com/) and Deep Space Exploration Society (https://dses.science/). This combined exhibit is a one-stop shop for the best in community, technical, and citizen science amateur radio activity.

We have a volunteer presenting on Artificial Intelligence and Machine Learning in Amateur Radio. The talk opens with a brief summary of the history of our relationship with created intelligence and then explores case studies of the use of artificial intelligence and machine learning in amateur radio. Talk is 1pm on Friday in Entrada B.

Open Research Institute at DEFCON32

We will present an Open Source Showcase at DEFCON in the Radio Frequency Village 12-13 August 2024, with accessible exhibits and demonstrations. Here is the list of scheduled project demonstrations.

Regulatory Efforts: ORI works hard for open source digital radio work and moves technology from proprietary and controlled to open and free in intelligent and mutually beneficial ways. Our work on ITAR, EAR, Debris Mitigation, AI/ML, and Synthetic Aperture Radar will be presented and explained. Find out more at https://github.com/OpenResearchInstitute/documents/tree/master/Regulatory

Ribbit: this open source communications protocol uses the highest performance error correction and modern techniques to turn any analog radio into a digital text terminal. No wires, no extra equipment.. Learn how to use this communications system and get involved in building a truly innovative open source tactical radio service. Find out more at https://www.ribbitradio.org

Satellite: ORI has the world’s first and only open source HEO/GEO communications satellite project. All working parts of the transponder project will be demonstrated, from Opulent Voice to antenna designs.

The Dumbbell antenna: We have an HF antenna design based on a highly effective inductive loading technique first written about in 1958. Learn about this antenna and find out how to make your own. Repository can be found at https://github.com/OpenResearchInstitute/dumbbell

RFBitBanger: an HF QRP system and novel digital protocol called SCAMP. Kit information and updates will be available. Get your Batch 2 kit today at https://www.ebay.com/itm/364783754396

Radar: Our regulatory and technical work in synthetic aperture radar will be demonstrated. One of our volunteers will be giving a talk about open source synthetic aperture radar in the RF Village speakers track. Here is the abstract.

Synthetic Aperture Radar (SAR) is one of the most useful and interesting techniques in radar, providing high resolution radar satellite images from relatively small satellites. SAR is not limited by the time of day or by atmospheric conditions. It complements satellite photography and other remote sensing techniques, revealing activity on the Earth that would otherwise be hidden. How does the magic happen? This talk will explain the basics of SAR in an accessible and friendly way. That’s the good news.

The bad news? SAR is controlled by ITAR, the International Traffic in Arms Regulations, and is listed in the USML, the United States Munitions List. ITAR regulates the export of defense articles and services and is administered by the US State Department. This includes both products and services as well as technical data. Such as, catalogs of high resolution radar imagary. The articles and services regulated by ITAR are identified in the USML. If ITAR doesn’t get you, then EAR just might. The Export Administration Regulations (EAR) are administered by the US Commerce Department, and items are listed on a Commerce Control List (CCL). Commercial products and services and dual-use items that are not subject to ITAR could be regulated by EAR. Even if you are free of ITAR and EAR, you may still be regulated by yet another agency, such as the FCC.

Regulation of SAR chills commercial activity, creating costly and time-consuming burdens. But why does any of this matter to signals hackers? Because technology has overtaken the rules, and devices used by enthusiasts, researchers, students, and hackers are increasingly likely to have enough capability to fall into export-controlled categories. The penalties are harsh. Fear of running afoul of ITAR is enough to stop a promising open source project in its tracks.

Is there a way forward? Yes. ITAR has a public domain carve out. Information that is published and that is generally accessible or available to the public is excluded from control as ITAR technical data. That’s great in theory, but how can we increase our confidence that we are interpreting these rules correctly? How can we use and build upon these rules, so that our community can learn and practice modern radio techniques with reduced fear and risk? Can we contribute towards regulatory relief when it comes to SAR? We will describe the process, report on the progress, and enumerate the challenges and roadblocks.

RFBitBanger Batch 2 Kits Available

Kits are available at our eBay store at this link https://www.ebay.com/itm/364783754396

Be a part of the future with a prototype Batch 2 kit build of the RFBitBanger, a low-power high-frequency digital radio by Dr. Daniel Marks KW4TI. Presented by Open Research Institute, this kit is designed to produce 4 watts of power and opens up a new digital protocol called SCAMP.

SCAMP Is now available in FLDigi!

Source code and extensive instructions can be found at https://github.com/profdc9/fldigi

Your donation in exchange for this kit directly enables the further development of an innovative Class E amplifier based radio design. It has a display, button menu navigation, and keyboard connection for keyboard modes and keyboard-enabled navigation. This radio can be taken portable or used in a case. If you have a 3d printer, then Dr. Marks has a design ready for you to print in the repository linked below.

  • Built-in digital modes: CW, RTTY, SCAMP (FSK and OOK, multiple speeds)
  • Key jack supports straight keys and iambic paddles
  • Open Source hardware and firmware, Arduino UNO compatible https://github.com/profdc9/RFBitBanger
  • External sound-card FSK digital modes supported (including FT4/FT8)
  • Experimental SSB support
  • Serial port support (2400 baud) for send and receive in keyboard modes

SCAMP is a new protocol that allows keyboard-to-keyboard contacts with a digital protocol that has excellent connection performance. See Dr. Marks presentation about RFBitBanger at QSO Today Academy in September 2023 to learn more about SCAMP and the RFBitBanger project. Link below:

All surface mount parts on the main board are pre-installed at the factory. All the through-hole parts you need to complete the radio are provided for you to solder yourself.

Builder’s notes and photos of all the components to help you identify and install them can be found here:

https://github.com/OpenResearchInstitute/RFBitBanger-kit/tree/main/batch2

If you don’t know how to wind toroids or solder surface mount capacitors, this is an excellent kit to learn on. There are just six toroids on the main board, and two on each band pass filter board. You can build just one band pass filter board and operate on a single band, or you can build an assortment. We provide 12 filter boards, enough toroids to build any 9 filters, and a supply of capacitors that will let you build those 9 filters for 9 different HF ham bands. These capacitors are size 1206, which is the largest common size for SMT capacitors and the easiest to solder manually. All you’ll need is a pair of tweezers and your regular soldering iron and solder. We provide detailed instructions on winding the toroids and soldering the capacitors. You get spare filter boards to experiment with.

Friendly Support is provided through a dedicated Open Research Institute Slack channel.

Instructions on how to join this community are here:

https://www.facebook.com/openresearchinstitute https://www.instagram.com/open_research_institute/
https://x.com/OpenResearchIns

Inner Circle Newsletter – All About the RFBitBanger

Three Days Remaining for the RFBitBanger HF Radio Kit DEFCON Show Special

Be a part of the future with a prototype kit build of the RFBitBanger, a low-power high-frequency digital radio by Dr. Daniel Marks KW4TI. Presented by Open Research Institute, this kit is designed to produce 4 watts of power and opens up a new digital protocol called SCAMP. Your donation in exchange for this kit directly enables the development of an innovative Class E amplifier based radio design. It has a display, button menu navigation, and keyboard connection for keyboard modes and keyboard-enabled navigation. This radio can be taken portable or used in a case. If you have a 3d printer, then Dr. Marks has a design ready for you to print.

  • Built-in digital modes: CW, RTTY, SCAMP (FSK and OOK, multiple speeds)
  • Key jack supports straight keys and iambic paddles
  • Open Source hardware and firmware, Arduino UNO compatible https://github.com/profdc9/RFBitBanger
  • External sound-card FSK digital modes supported (including FT4/FT8)
  • Experimental SSB support
  • Serial port support (2400 baud) for send and receive in keyboard modes

SCAMP is a new protocol that allows keyboard-to-keyboard contacts with a digital protocol that has excellent connection performance. See Dr. Marks presentation about RFBitBanger at QSO Today Academy in September 2023 to learn more about SCAMP and the RFBitBanger project. Information about that event is here: https://www.qsotodayhamexpo.com/

All surface mount parts on the main board are pre-installed at the factory. All the through-hole parts you need to complete the radio are provided for you to solder yourself. If you don’t know how to wind toroids or solder surface mount capacitors, this is an excellent kit to learn on. There are just six toroids on the main board, and two on each band pass filter board. You can build just one band pass filter board and operate on a single band, or you can build an assortment. We provide 12 filter boards, enough toroids to build any 9 filters, and a supply of capacitors that will let you build those 9 filters for 9 different HF ham bands. These capacitors are size 1206, which is the largest common size for SMT capacitors and the easiest to solder manually. All you’ll need is a pair of tweezers and your regular soldering iron and solder. We provide detailed instructions on winding the toroids and soldering the capacitors. You get spare filter boards to experiment with.

Support is provided through a dedicated Open Research Institute Slack channel.

Instructions on how to join the ORI community are here:
https://openresearch.institute/getting-started

Delivery is no earlier than late August 2023. Will be posted here and on the ORI website at https://www.openresearch.institute/rfbitbanger-project/

If you missed this sale, check out the upcoming show special at QSO Today Academy.

Want to Learn More About RFBitBanger?

Project lead Dr. Daniel Marks will give a presentation about the RFBitBanger at QSO Today Academy 9 September 2023 1300 PDT, 0800 UTC.

Daniel Marks, KW4TI, is a Ph.D. in Electrical Engineering, having graduated from the University of Illinois at Urbana-Champaign in 2001. His fields of speciality include optical engineering, computed imaging, and signal processing. He has made dozens of open hardware projects including many for amateur radio.

https://wze95h.qsotodayhamexpo.com/sessionInfo/_the_rfbitbanger_an_off_the_grid_emergency

The recent shortage of semiconductors, parts important for electronics, shows us that supply chains can be fragile. What does this mean? It means if we have a big problem for a long time, our advanced radios might be tough to keep working, which could be a problem in an emergency.

To solve this, a new kind of radio called the RFBitBanger has been created. It’s a type of low power, long-distance radio that is easy to build from basic parts using simple tools. It uses a new digital language, called SCAMP, made specifically for this radio.

All the signal work is done by an Arduino processor. What’s cool is that the radio has a small screen and buttons or you can even attach a keyboard. It’s a full text communications system all by itself. SCAMP is pretty special too. Even though it only needs a simple 8-bit microcontroller, it can do lots of things that digital modes like FT8 can do using small bandwidth and something called forward error correction.

The RFBitBanger radio has other helpful features. It can support CW (which is Morse code), RTTY (another way of sending text), and SSB phone (voice communication).

We hope that the RFBitBanger can serve as an easy-to-build and easy-to-maintain emergency radio. It can also be a great educational kit. And, it can be a lifesaver when there’s a big shortage of parts.

Media for RFBitBanger

Thank you to Hackaday and QRZ forums for covering the RFBitBanger project. Here are the links to the articles.

https://www.hackster.io/news/daniel-marks-rfbitbanger-is-a-qrp-radio-kit-for-the-end-of-civilization-or-for-fun-6ee3b5956eb7

https://www.qrz.com/articles/node_1692683709

Inner Circle Newsletter April 2023

Welcome to our newsletter for April 2023!

Inner Circle is your update on what’s happening at and adjacent to Open Research Institute. We’re a non-profit dedicated to open source digital radio work. We support technical and regulatory efforts. A major beneficiary of this work is the amateur radio services. Sign up at this link http://eepurl.com/h_hYzL

Contents:

  • Guest Editorial by Dr. Daniel Estévez Amaranth in Practice
  • Federal Communications Commission Technological Advisory Council resumes!
  • HDL Coder for Software Defined Radio Class May 2023
  • FPGA Workshop Cruise with ORI?
Markdown preview

Amaranth in practice: a case study with Maia SDR

Maia SDR is a new open-source FPGA-based SDR project focusing on the ADALM Pluto. The longer term goals of the project are to foster open-source development of SDR applications on FPGA and to promote the collaboration between the open-source SDR and FPGA communities. For the time being, focusing on developing a firmware image for the ADALM Pluto that uses the FPGA for most of the signal processing provides realistic goals and a product based on readily available hardware that people can already try and use during early stages of development.

The first version of Maia SDR was released on Februrary 2023, though its development started in September 2022. This version has a WebSDR-like web interface that displays a realtime waterfall with a sample rate of up to 61.44Msps and is able to make IQ recordings at that rate to the Pluto DDR (up to a maximum size of 400MiB per recording). These recordings can then be downloaded in SigMF format.

Exploring the RF world in the field with a portable device is one of the goals of Maia SDR, so its web UI is developed having in mind the usage from a smartphone and fully supports touch gestures to zoom and scroll the waterfall. A Pluto connected by USB Ethernet to a smartphone already give a quite capable and portable tool to discover and record signals.

The following figure shows a screenshot of the Maia SDR web user interface. More information about the project can be found in https://maia-sdr.net

Amaranth

Amaranth is an open-source HDL based in Python. The project is led by Catherine “whitequark”, who is one of the most active and prolific developers in the open-source FPGA community. Amaranth was previously called nMigen, as it was initially developed as an evolution of the Migen FHDL by M-Labs.

I cannot introduce Amaranth any better than Catherine, so I will just cite her words from the README and documentation.

The Amaranth project provides an open-source toolchain for developing hardware based on synchronous digital logic using the Python programming language, as well as evaluation board definitions, a System on Chip toolkit, and more. It aims to be easy to learn and use, reduce or eliminate common coding mistakes, and simplify the design of complex hardware with reusable components.

The Amaranth toolchain consists of the Amaranth hardware definition language, the standard library, the simulator, and the build system, covering all steps of a typical FPGA development workflow. At the same time, it does not restrict the designer’s choice of tools: existing industry-standard (System)Verilog or VHDL code can be integrated into an Amaranth-based design flow, or, conversely, Amaranth code can be integrated into an existing Verilog-based design flow.

The Amaranth documentation gives a tutorial for the language and includes as a first example the following counter with a fixed limit.

from amaranth import *

class UpCounter(Elaboratable):
    """
    A 16-bit up counter with a fixed limit.

    Parameters
    ----------
    limit : int
        The value at which the counter overflows.

    Attributes
    ----------

    en : Signal, in
        The counter is incremented if ``en`` is asserted, and retains
        its value otherwise.
    ovf : Signal, out
        ``ovf`` is asserted when the counter reaches its limit.
    """
    def __init__(self, limit):
        self.limit = limit

        # Ports
        self.en  = Signal()
        self.ovf = Signal()

        # State
        self.count = Signal(16)

    def elaborate(self, platform):
        m = Module()

        m.d.comb += self.ovf.eq(self.count == self.limit)

        with m.If(self.en):
            with m.If(self.ovf):
                m.d.sync += self.count.eq(0)
            with m.Else():
                m.d.sync += self.count.eq(self.count + 1)

        return m

Amaranth Elaboratable‘s are akin to Verilog module‘s (and in fact get synthesized to module‘s if we convert Amaranth to Verilog). IO ports for the module are created in the __init__() method. The elaborate() method can create additional logic elements besides those created in __init__() by instantiating more Signal‘s (this example does not do this). It also describes the logical relationships between all these Signals by means of a Module() instance usually called m. Essentially, at some point in time, the value of a Signal changes depending on the values of some Signal‘s and potentially on some conditions. Such point in time can be either continuously, which is described by the m.d.comb combinational domain, or at the next rising clock edge, which is described by the m.d.sync synchronous domain (which is, roughly speaking, the “default” or “main” clock domain of the module), or by another clock domain. Conditions are expressed using with statements, such as with m.If(self.en), in a way that feels quite similar to writing Python code.

For me, one of the fundamental concepts of Amaranth is the division between what gets run by Python at synthesis time, and what gets run by the hardware when our design eventually comes to life in an FPGA. In the elaborate() method we have a combination of “regular” Python code, which will get run in our machine when we convert the Amaranth design to Verilog or generate a bitstream directly from it, as well as code that describes what the hardware does. The latter is also Python code, but we should think that the effects of running it are only injecting that description into the list of things that Amaranth knows about our hardware design.

Code describing the hardware appears mainly in two cases: First, when we operate with the values of signals. For instance, self.count + 1 does not take the value of self.count and add one to it when the Python code is run. It merely describes that the hardware should somehow obtain the sum of the value of the register corresponding to self.count and the constant one. This expression is in effect describing a hardware adder, and it will cause an adder to appear in our FPGA design. This behaviour is reminiscent of how Dask and other packages based on lazy evaluation work (in Dask, operations with dataframes only describe computations; the actual work is only done eventually, when the compute() method is called). I want to stress that the expression self.count + 1 might as well appear in elaborate() only after a series of fairly complicated if and else statements using regular Python code. These statements will be evaluated at synthesis time, and our hardware design will end up having an adder or not depending on these conditions. Similarly, instead of the constant 1 in the + 1 operation, we could have a Python variable that is evaluated in synthesis time, perhaps as the result of running fairly complicated code. This will also affect what constant the hardware adder that we have in our design adds to the value of the self.count register.

Secondly, we have the control structures: m.If, m.Else, and a few more. These also describe hardware. Whether the condition is satisfied is not evaluated when the Python script runs. What these conditionals do is to modify the hardware description formed by the assignments to m.d.sync and m.d.comb that they enclose so that these assignments are only effective (or active) in the moments in which the condition is satisfied. In practice, these statements do two things in the resulting hardware: They multiplex between several intermediate results depending on some conditions, in a way that is usually more readable than using the Mux() operator that Amaranth also provides. They also control what logic function gets wired to the clock enable of flip-flops. Indeed, in some conditions a synchronous Signal() may have no active statements, in which case it should hold its current value. This behaviour can be implemented in hardware either by deasserting the clock enable of the flip-flops or by feeding back the output of the flip-flops to their input through a multiplexer. What is done depends mainly on choices done by the synthesis tool when mapping the RTL to FPGA elements. As before, we can have “regular” Python code that is run at synthesis time modifying how these m.If control structures look like, or even whether they appear in the design at all.

In a sense, the regular Python code that gets run at synthesis time is similar to Verilog and VHDL generate blocks. However, this is extremely more powerful, because we have all the expressiveness and power of Python at our disposal to influence how we build our design at synthesis time. Hopefully the following examples from Maia SDR can illustrate how useful this can be.

maia-hdl

maia-hdl is the FPGA design of Maia SDR. It is bundled as a Python package, with the intention to make easy to reuse the modules in third party designs. The top level of the design is an Amaranth Elaboratable that gets synthesized to Verilog and packaged as a Vivado IP core. As shown below, the IP core has re_in and im_in ports for the IQ data of the ADC, an AXI4-Lite subordinate interface to allow the ARM processor to control the core through memory-mapped registers, AXI3 manager interfaces for the DMAs of the spectrometer (waterfall) and IQ recorder, and ports for clocking and reset.

The IP core is instantiated in the block design of a Vivado project that gets created and implemented using a TCL script. This is based on the build system used by Analog Devices for the default Pluto FPGA bitstream. In this respect, Maia SDR gives a good example of how Amaranth can be integrated in a typical flow using the Xilinx tools.

There are two classes of unit tests in maia-hdl. The first are Amaranth simulations. These use the Amaranth simulator, which is a Python simulator than can only simulate Amaranth designs. These tests give a simple but efficient and powerful way of testing Amaranth-only modules. The second are cocotb simulations. Cocotb is an open-source cosimulation testbench environment for verifying VHDL and Verilog designs using Python. Briefly speaking, it drives an HDL simulator using Python to control the inputs and check the outputs of the device under test. Cocotb has rich environment that includes Python classes that implement AXI devices. In maia-hdl, cocotb is used together with Icarus Verilog for the simulation of designs that involve Verilog modules (which happens in the cases in which we are instantiating from Amaranth a Xilinx primitive that is simulated with the Unisim library), and for those simulations in which the cocotb library is specially useful (such as for example, when using the cocotb AXI4-Lite Manager class to test our AXI4-Lite registers).

One of the driving features of Maia SDR is to optimize the FPGA resource utilization. This is important, because the Pluto Zynq-7010 FPGA is not so large, specially compared with other Xilinx FPGAs. To this end, Amaranth gives a good control about how the FPGA design will look like in terms of LUTs, registers, etc. The example with the counter has perhaps already shown that Amaranth is a low-level language, in the same sense that Verilog and VHDL are, and nothing comparable to HLS (where regular C code is translated to an FPGA design).

FFT

The main protagonist of the Maia SDR FPGA design is a custom pipelined FFT core that focuses on low resource utilization. In the Maia SDR Pluto firmware it is used as a radix-2² single-delay-feedback decimation-in-frequency 4096-point FFT with a Blackman-harris window. It can run at up to 62.5 Msps and uses only around 2.2 kLUTs, 1.4 kregisters, 9.5 BRAMs, and 6 DSPs. One of the tricks that allows to save a lot of DSPs is to use a single DSP for each complex multiplication, by performing the three required real products sequentially with a 187.5 MHz clock. A description of the design of the FFT core is out of the scope of this article, but I want to show a few features that showcase the strengths of Amaranth.

The first is the FFTControl module. The job of this module is to generate the control signals for all the elements of the FFT pipeline. In each clock cycle, it selects which operation each butterfly should do, which twiddle factor should be used by each multiplier, as well as the read and write addresses to use for the delay lines that are implemented with BRAMs (these are used for the first stages of the pipeline, which require large delay lines). As one can imagine, these control outputs are greatly dependent on the synchronization of all the elements. For example, if we introduce an extra delay of one cycle in one of the elements, perhaps because we register the data to satisfy timing constraints, all the elements following this in the pipeline will need their control inputs to be offset in time by one cycle.

It is really difficult to implement something like this in Verilog or VHDL. Changing these aspects of the synchronization of the design usually requires rethinking and rewriting parts of the control logic. In Amaranth, our modules are Python classes. We can have them “talk to each other” at synthesis time and agree on how the control should be set up, in such a way that the result will still work if we change the synchronization parameters.

For example, all the classes that are FFT pipeline elements implement a delay Python @property that states what is the input to output delay of the module measured in clock cycles. For some simple modules this is always the same constant, but for a single-delay-feedback butterfly it depends on the length of the delay line of the butterfly, and for a twiddle factor multiplier it depends on whether the multiplier is implemented with one or three DSPs. These are choices that are done at synthesis time based on parameters that are passed to the __init__() method of these modules.

The FFTControl module can ask at synthesis time to all the elements that form the FFT pipeline what are their delays, and figure out the reset values of some counters and the lengths of some delay lines accordingly. This makes the control logic work correctly, regardless what these delays are. For instance, the following method of FFTControl computes the delay between the input of the FFT and the input of each butterfly by summing up the delays of all the preceding elements.

def delay_butterflies_input(self):
    """Gives the delay from the FFT input to the input of each of the
    butterflies"""
    return [
        self.delay_window
        + sum([butterfly.delay for butterfly in self.butterflies[:j]])
        + sum([twiddle.delay for twiddle in self.twiddles[:j]])
        for j in range(self.stages)
    ]

This is then used in the calculation of the length of some delay lines that supply the control signals to the butterflies. The code is slightly convoluted, but accounts for all possible cases. I don’t think it would be reasonable to do this kind of thing in Verilog or VHDL.

mux_bfly_delay = [
    [Signal(2 if isinstance(self.butterflies[j], R22SDF) else 1,
            name=f'mux_bfly{j}_delay{k}', reset_less=True)
     for k in range(0,
                    delay_butterflies_input[j]
                    - delay_twiddles_input[j-1]
                    + self.twiddles[j-1].twiddle_index_advance)]
     for j in range(1, self.stages)]

Another important aspect facilitated by Amaranth is the construction of a model. We need a bit-exact model of our FFT core in order to be able to test it in different situations and to validate simulations of the Amaranth design against the model. Each of the modules that form the pipeline has a model() method that uses NumPy to calculate the output of that module given some inputs expressed as NumPy arrays. Here is the model for a radix-2 decimation-in-frequency single-delay-feedback butterfly. Perhaps it looks somewhat reasonable if we remember that such a butterfly basically computes first x[n] + x[n+v//2], for n = 0, 1, ..., v//2-1, and then x[n] - x[n+v//2] for n = 0, 1, ..., v//2-1.

[class R2SDF(Elaboratable):]
[...]
def model(self, re_in, im_in):
    v = self.model_vlen
    re_in, im_in = (np.array(x, 'int').reshape(-1, 2, v // 2)
                    for x in [re_in, im_in])
    re_out, im_out = [
        clamp_nbits(
            np.concatenate(
                (x[:, 0] + x[:, 1], x[:, 0] - x[:, 1]),
                axis=-1).ravel() >> self.trunc,
            self.w_out)
        for x in [re_in, im_in]]
    return re_out, im_out

The interesting thing is that, since each of the FFT pipeline modules has its individual model, it is easy to verify the simulation of each module against its model separately. The model of the FFT module, which represents the whole FFT core, simply puts everything together by calling the model() methods of each of the elements in the pipeline in sequence. An important detail here is that the arrays self._butterflies and self._twiddles are the same ones that are used to instantiate and connect together the pipeline modules, in terms of the hardware design. By having these synergies between the model and the hardware design, we reduce the chances of them getting out of sync due to code changes.

[class FFT(Elaboratable):]
[...]
def model(self, re_in, im_in):
    v = self.model_vlen
    re = re_in
    im = im_in
    if self._window is not None:
        re, im = self._window.model(re, im)
    for j in range(self.nstages):
        re, im = self._butterflies[j].model(re, im)
        if j != self.nstages - 1:
            re, im = self._twiddles[j].model(re, im)
    return re, im

Instantiating Verilog modules and primitives

A question that often comes up is how to instantiate Verilog modules, VHDL entities or FPGA primitives in an Amaranth design. Kate Temkin has a short blog post about it. In maia-hdl this is used in in several cases, such as to implement clock domain crossing with the Xilinx FIFO18E1 primitive. The most interesting example is however the Cmult3x module, which implements complex multiplication with a single DSP48E1 that runs at three clock cycles per input sample (some simple algebra shows that a complex multiplication can be written with only three real multiplications).

When designing modules with DSPs, I prefer to write HDL code that will make Vivado infer the DSPs I want. This is possible in simple cases, but in more complicated situations it is not possible to make Vivado understand exactly what we want, so we need to instantiate the DSP48 primitives by hand.

The drawback of having an Amaranth design that contains instances of Verilog modules, VHDL entities or primitives is that we can no longer simulate our design with the Amaranth simulator. If our instances have a Verilog model (such as is the case with Xilinx primitives via the Unisim library), we can still convert the Amaranth design to Verilog and use a Verilog simulator. This is done in maia-hdl using Icarus Verilog and cocotb. However, this can be somewhat inconvenient.

There is another possibility, which is to write different implementations of the same Amaranth module. One of them can be pure Amaranth code, which we will use for simulation, and another can use Verilog modules or primitives. The two implementations need to be functionally equivalent, but we can check this through testing.

The way to acomplish this is through Amaranth’s concept of platform. The platform is a Python object that gets passed to the elaborate() methods of the modules in the design. The elaborate methods can then ask the platform for some objects that are usually dependent on the FPGA family, such as flip-flop synchronizers. This is a way of building designs that are more portable to different families. The platform objects are also instrumental in the process of building the bitstream completely within Amaranth, which is possible for some FPGA families that have an open-source toolchain.

In the case of the maia-hdl Cmult3x we simply check whether the platform we’ve been passed is an instance of XilinxPlatform and depending on this we have the elaborate() method either describe a pure Amaranth design that models the DSP48 functionality that we need, or instantiate a DSP48E1 primitive. Note that in the case of the pure Amaranth design we do not model the full functionality of the DSP48. Only that which is applicable to this use case.

[class Cmult3x(Elaboratable):]
[...]
def elaborate(self, platform):
    if isinstance(platform, XilinxPlatform):
        return self.elaborate_xilinx(platform)

    # Amaranth design. Vivado doesn't infer a single DSP48E1 as we want.
    [ ... here a pure amaranth design follows ... ]

def elaborate_xilinx(self, platform):
    # Design with an instantiated DSP48E1
    [...]
    m.submodules.dsp = dsp = Instance(
        'DSP48E1',
    [...]

Registers

Another aspect where the flexibility of Amaranth shines is in the creation of register banks. In maia-hdl, the module Register corresponds to a single 32-bit wide register and the module Registers forms a register bank by putting together several of these registers, each with their corresponding address. The registers support a simple bus for reads and writes, and an Axi4LiteRegisterBridge module is provided to translate between AXI4-Lite and this bus, allowing the ARM CPU to access the registers.

Registers and register banks are created with Python code that describes the fields of the registers. The basic ingredient is the Field named tuple:

Field = collections.namedtuple('RegisterField',
                               ['name', 'access', 'width', 'reset'])

We describe a register by giving it a name, an access mode (which can be read-only, write-only, read-write, or some other more specialized modes that we will describe below), a width, and a reset or default value.

The best way to understand how to work with these registers is to see how they are used in the Maia SDR top-level design.

self.control_registers = Registers(
    'control',
    {
        0b00: Register(
            'product_id', [
                Field('product_id', Access.R, 32, 0x6169616d)
            ]),
        0b01: Register('version', [
            Field('bugfix', Access.R, 8,
                  int(_version.split('.')[2])),
            Field('minor', Access.R, 8,
                  int(_version.split('.')[1])),
            Field('major', Access.R, 8,
                  int(_version.split('.')[0])),
            Field('platform', Access.R, 8, 0),
        ]),
        0b10: Register('control', [
            Field('sdr_reset', Access.RW, 1, 1),
        ]),
        0b11: Register('interrupts', [
            Field('spectrometer', Access.Rsticky, 1, 0),
            Field('recorder', Access.Rsticky, 1, 0),
        ], interrupt=True),
    },
    2)
self.recorder_registers = Registers(
    'recorder',
    {
        0b0: Register('recorder_control', [
            Field('start', Access.Wpulse, 1, 0),
            Field('stop', Access.Wpulse, 1, 0),
            Field('mode_8bit', Access.RW, 1, 0),
            Field('dropped_samples', Access.R, 1, 0),
        ]),
        0b1: Register('recorder_next_address', [
            Field('next_address', Access.R, 32, 0),
        ]),
    },
    1)

Here we show two register banks: one for the control of the IP core and another for the control of the IQ recorder. There is a similar third register bank for the control of the spectrometer (waterfall).

The parameters of the Registers constructor are a name, a dictionary that contains the registers in the bank (the keys of the dictionary are the addresses, and the values are the Register objects), and the width of the address bus. Note that these addresses correspond to the addressing of the native register bus. When we convert to AXI4-Lite, the addresses get shifted by two bits to the left because each register is 4 bytes wide.

The parameters of the Register constructor are a name and a list of Field‘s describing the fields of the register. Fields are allocated into the 32-bit register according to their order in the list, starting by the LSB. For instance, in the interrupts register, the spectrometer field occupies the LSB and the recorder field occupies the next bit.

If we look at the control registers, we can see that the registers for product_id and version have access type R, which means read-only. These registers are never wired in the design to other signals that would override their default values, so they are in fact constants that the CPU can read to check that the IP core is present and find its version number.

Next we have a control register, which has an sdr_reset field. This is wired internally to a bunch of reset signals in the IP core. It has a default value of 1, which means that most of the IP core starts in reset. The CPU can write a 0 to this field to take the IP core out of reset before using it. Accessing this sdr_reset field within the design is very simple, because the Registers and Register implement __getitem__(), allowing us to access them as if they were dictionaries. This example shows how it works. Here we are connecting the field sdr_reset to the reset input of something called rxiq_cdc (which implements clock domain crossing between the ADC sampling clock and the internal clock used in the IP core).

m.d.comb += rxiq_cdc.reset.eq(
    self.control_registers['control']['sdr_reset'])

If we look at the interrupts register, we can see an example of the Rsticky access mode. This means read-only sticky. A field of this type will be set to 1 when its input (which is wired internally in the IP core) has the value 1. It will keep the value 1 even if the input goes back to 0. The field is cleared and set to 0 when it is read. The intended use for this access mode is interrupts. A module can pulse the input of the field to notify an interrupt, and the field will hold a 1 until the CPU reads the register, clearing the interrupts. The interrupts register even has an interrupt=True option that provides an interrupt output that can be connected directly to the F2P interrupt port of the Zynq. This interrupt output will be high whenever any Rsticky field in the register is non-zero.

Finally, the recorder_control field gives some examples of the Wpulse access type. This is a write-only field with pulsed output. Writing a 1 to this field causes a one-cycle pulse at its output. This is ideal for controlling modules that require a pulse to indicate some event or command. For example, this is the case with the start and stop commands of the IQ recorder.

The Amaranth code that makes all of this work is not so complicated. You can take a look at the register.py file in maia-hdl to see for yourself.

Another interesting feature of this register system is that it can write an SVD file describing the register map. CMSIS-SVD is an XML format that is often used to describe the register maps of microcontrollers and SoCs. Maia SDR uses svd2rust to generate a nice Rust API for register access.

The Registers and Register classes have svd() methods that generate the SVD XML using Python’s xml.etree.ElementTree. This is relatively simple, because the classes already have all the information about these registers. It is, after all, the same information that they use to describe the hardware implementation of the registers. This is another example of how by using synergies between the code that describes the hardware design and code that does something related to that hardware design (in this case, writing SVD), we make it harder for changes in the code base to cause inconsistencies.

Conclusions

In this article we have gone from a “hello world” type counter in Amaranth to some rather intricate code from the inner workings of an FFT core. My intention with giving these code examples is not to expect the reader to understand all the code, but rather to give a feeling for how using Amaranth in complex projects can look like. Perhaps by now I have managed to convince you that Amaranth is a powerful and flexible alternative to HDLs such as Verilog and VHDL, or at least to get you interested in learning more about Amaranth and the world of open-source FPGA and silicon design.

Federal Communications Commission Technological Advisory Council resumes!

Want someone on your side at the FCC? We have good news. The FCC TAC is going to resume work. The previous term ended in December 2022 with an in-person meeting in Washington, DC. ORI was a member of the AI/ML Working Group and served as a co-chair of the “Safe Uses of AI/ML” sub-working group. The next term will be for two years. The appointment will require another round of nominations and vetting. An invitation to ORI has been made. ORI will speak up for open source digital radio work and the amateur radio services. Thank you to everyone that made the 2022 FCC TAC term productive and beneficial. Join the #ai channel on ORI Slack to get more involved. Not part of Slack? Visit https://openresearch.institute/getting-started to Get Started.

HDL Coder for Software Defined Radio Class May 2023

Sign-ups are live at https://us.commitchange.com/ca/san-diego/open-research-institute/campaigns/hdl-coder-for-software-defined-radio

Advanced training for Digital Communications, Software Defined Radio, and FPGAs will be held 1-5 May 2023. Do you know someone that can benefit from customized and focused training? Please forward this email to them. Designed to benefit open source digital radio, this course also benefits the amateur radio services.

Presented by ORI and taught by Mathworks, this class will cover the following topics.

COURSE OUTLINE

Day 1 – Generating HDL Code from Simulink & DSP for FPGAs

Preparing Simulink Models for HDL Code Generation (1.0 hrs)

Prepare a Simulink model for HDL code generation. Generate HDL code and testbench for simple models requiring no optimization.

  • Preparing Simulink models for HDL code generation
  • Generating HDL code
  • Generating a test bench
  • Verifying generated HDL code with an HDL simulator

Fixed-Point Precision Control (2.0 hrs)

Establish correspondence between generated HDL code and specific Simulink blocks in the model. Use Fixed-Point Tool to finalize fixed point architecture of the model.

  • Fixed-point scaling and inheritance
  • Fixed-Point Designer workflow
  • Fixed-Point Tool
  • Fundamental adders and multiplier arrays
  • Division and square root arrays
  • Wordlength issues and Fixed-point arithmetic
  • Saturate and wraparound.
  • Overflow and underflow

Optimizing Generated HDL Code (4 hrs)

Use pipelines to meet design timing requirements. Use specific hardware implementations and share resources for area optimization.

  • Generating HDL code with the HDL Workflow Advisor
  • Meeting timing requirements via pipelining
  • Choosing specific hardware implementations for compatible Simulink blocks
  • Sharing FPGA/ASIC resources in subsystems
  • Verifying that the optimized HDL code is bit-true cycle-accurate
  • Mapping Simulink blocks to dedicated hardware resources on FPGA

Day 2 – DSP for FPGAs

Signal Flow Graph (SFG) Techniques (SFG) Techniques and high-speed FIR design (2.0 hrs)

Review the representation of DSP algorithms using signal flow graph. Use the Cut Set method to improve timing performance. Implement parallel and serial FIR filters.

  • DSP/Digital Filter Signal Flow Graphs
  • Latency, delays and “anti-delays”!
  • Re-timing: Cut-set and delay scaling
  • The transpose FIR
  • Pipelining and multichannel architectures
  • SFG topologies for FPGAs
  • FIR filter structures for FPGAs

Multirate Signal Processing for FPGAs (4.0 hrs)

Develop polyphase structure for efficient implementation of multirate filters. Use CIC filter for interpolation and decimation.

  • Upsampling and interpolation filters
  • Downsampling and decimation filters
  • Efficient arithmetic for FIR implementation
  • Integrators and differentiators
  • Half-band, moving average and comb filters
  • Cascade Integrator Comb (CIC) Filters (Hogenauer)
  • Efficient arithmetic for IIR Filtering

CORDIC Techniques AND channelizers (2.0 hrs)

Introduce CORDIC algorithm for calculation of various trigonometric functions.

  • CORDIC rotation mode and vector mode
  • Compute cosine and sine function
  • Compute vector magnitude and angle
  • Architecture for FPGA implementation
  • Channelizer

Day 3 – Programming Xilinx Zynq SoCs with MATLAB and Simulink & Software-Defined Radio with Zynq using Simulink

IP Core Generation and Deployment (2.0 hrs)

Use HDL Workflow Advisor to configure a Simulink model, generate and build both HDL and C code, and deploy to Zynq platform.

  • Configuring a subsystem for programmable logic
  • Configuring the target interface and peripherals
  • Generating the IP core and integrating with SDK
  • Building and deploying the FPGA bitstream
  • Generating and deploying a software interface model
  • Tuning parameters with External Mode

Model Communications System using Simulink (1.5 hrs)

Model and simulate RF signal chain and communications algorithms.

  • Overview of software-defined radio concepts and workflows
  • Model and understand AD9361 RF Agile Transceiver using Simulink
  • Simulate a communications system that includes a transmitter, AD9361 Transceiver, channel and Receiver (RF test environment)

Implement Radio I/O with ADI RF SOM and Simulink (1.5 hrs)

Verify the operation of baseband transceiver algorithm using real data streamed from the AD9361 into MATLAB and Simulink.

  • Overview of System object and hardware platform
  • Set up ADI RF SOM as RF front-end for over-the-air signal capture or transmission
  • Perform baseband processing in MATLAB and Simulink on captured receive signal
  • Configure AD9361 registers and filters via System object
  • Verify algorithm performance for real data versus simulated data

Prototype Deployment with Real-Time Data via HW/SW Co-Design (2.0 hrs)

Generate HDL and C code targeting the programmable logic (PL) and processing system (PS) on the Zynq SoC to implement TX/RX.

  • Overview of Zynq HW/SW co-design workflow
  • Implement Transmitter and Receiver on PL/PS using HW/SW co-design workflow
  • Configure software interface model
  • Download generated code to the ARM processor and tune system parameters in real-time operation via Simulink
  • Deploy a stand-alone system

FPGA Workshop Cruise with ORI?

Want to learn more about open source FPGA development from experts in the field? Ready to capitalize on the HDL Coder for Software Defined Radio Class happening in May 2023? Want to get away? How about something that can give you both? We are looking at organizing an FPGA Workshop Adventure Cruise. Be part of the planning and write fpga@openresearch.institute

Are you interested in supporting work at ORI?

Consider being part of the board. We’d like to expand from 5 to 7 members in order to better serve our projects and community.

We’ve got lots going on with Opulent Voice, Haifuraiya, AmbaSat Respin, and regulatory work.

Thank you from everyone at ORI for your continued support and interest!

Want to be a part of the fun? Get in touch at ori@openresearch.institute

Inner Circle Newsletter March 2023

March 2023 Inner Circle
Welcome to our newsletter for March 2023!

Inner Circle is a non-technical update on everything that is happening at ORI. Sign up at this link http://eepurl.com/h_hYzL

Contents:
FPGA Workshop Cruise with ORI?
ORI’s Birthday 6 March – Celebrate With Pins!
RFBitBanger Prototypes
Announcing the ORI App Stores
QSO Today Ham Expo Spotlight
Jay Francis in QEX
Pierre W4CKX Declares Candidacy for ORI Board of Directors

FPGA Workshop Cruise with ORI?
Want to learn more about open source FPGA development from experts in the field? Want to get away? How about something that can give you both? We are looking at organizing an FPGA Workshop Adventure Cruise. Be part of the planning and write fpga@openresearch.institute

ORI’s Birthday – Celebrate With Pins!
We celebrate our 4th birthday on 6 March 2023. Thank you to everyone that has helped ORI grow and succeed in so many different ways. To commemorate our anniversary, we have a limited edition acrylic logo pin. They will be available for a small donation at all upcoming in-person events. Where will be be? We’ll be at DEFCON 31 and IEEE IWRC in Little Rock, AR, USA 13-14 September 2023. Want to include us at your event before then? Let us know at hello@openresearch.institute

RFBitBanger Prototypes
Interested in high frequency amateur (HF) bands? Want to learn about Class E amplification? Excited about open HF digital protocols that aren’t just signal reports? Well, we have a kit for you. Here’s a walk-through by Paul KB5MU of all RFBitBanger modes. This project is lead by Dr. Daniel Marks, is enthusiastically supported by ORI, and will be demonstrated at DEFCON in August 2023. We are doing all we can to have kits available for sale by DEFCON, or sooner.

Announcing the ORI App Stores
Open Research Institute can be found in the Google Play Store and the Apple App Store. That’s right – we are in both app stores delivering open source mobile apps. Thank you to everyone that has helped make this possible. The Ribbit app will be available on both platforms as our initial release. Do you know of an open source application that needs a home? Get in touch at hello@openresearch.institute and let’s talk. We want to share our platform and support applications that help open source and amateur radio.

QSO Today Ham Expo Spotlight
We hope to see you again at QSO Today Ham Expo, 25-26 March 2023. If you haven’t gotten a ticket yet, please visit https://www.qsotodayhamexpo.com/
This is a wonderful event that showcases the best parts of amateur radio. The theme for this Ham Expo is “New License – Now What?” Recordings will be available on the Ham Expo platform for a month, and then will be available on YouTube for anyone to view. ORI will volunteer at the March 2023 QSO Ham Expo session and will have technical presentations, a booth, and poster sessions at the Autumn 2023 QSO Today Ham Expo.

Jay Francis in QEX
Please see page 20 of the March/April 2023 issue of QEX magazine for an article co-authored by Jay Francis, our AmbaSat Re-Spin team lead. Excellent job, Jay!

Pierre W4CKX has declared his candidacy for ORI Board of Directors
We welcome Pierre’s interest in being a member of the board. Pierre is the Ribbit project lead. He brings broad industry knowledge, experience in Agile project management, a commitment to ethical leadership, and innovative energy. Learn about all our directors at https://www.openresearch.institute/board-of-directors/

Are you interested in supporting work at ORI? Consider being part of the board. We’d like to expand from 5 to 7 members in order to better serve our projects and community.

We’ve got lots going on with Opulent Voice, Haifuraiya, AmbaSat Respin, and regulatory work. We support IEEE in many ways, one of which is logistics support with technical presentations such as “Advances in AI for Web Integrity, Ethics, and Well Being” by Srijan Kumar PhD. Video recording of his talk can be found here.

Thank you from everyone at ORI for your continued support and interest!

Whatever will be do for our April 1st newsletter?

Want to be a part of the fun? Get in touch at ori@openresearch.institute

Inner Circle Newsletter February 2023

Greetings all! Welcome to the February 2023 issue of the Inner Circle Newsletter from Open Research Institute.

Join the Inner Circle

Sign up for this newsletter at http://eepurl.com/h_hYzL

Thank you so much for your time, attention, and support. We appreciate you, we welcome your feedback, and we are dedicated to serving the community to the best of our abilities. You can get in touch with the ORI board of directors directly at hello@operesearch.institute.

A Puzzle Just For Fun

Here’s a puzzle. Chicken Nuggets have been on the menu at the international fast food chain McDonald’s since 1983.

If Chicken McNuggets are sold in packs of 6, 9, or 20, then what is the largest number of nuggets that cannot be ordered?

Answer is at the end of this newsletter!

Projects

Our volunteer teams have been busy and successful, and our project lineup has grown.

Regulatory Efforts: ORI works hard to promote and defend open source digital radio work. We do all we can to help move technology from proprietary and controlled to open and free. Our work on ITAR, EAR, Debris Mitigation, and AI/ML are where we have spent most of our time over the past two years. We were a member of the Technological Advisory Committee for the US Federal Communications Commission in 2022, and co-chaired the Safe Uses of AI/ML Subworking Group. We have received consistently positive reviews for all of our work, and there has been increasing use of the results.

Ribbit: this open source communications protocol uses the highest performance error correction and modern techniques available to turn any analog radio into an efficient and useful digital text terminal. No wires, no extra equipment. The only thing you’ll need to use it is the free open source Android or IoS app on your phone. Learn how to use this communications system and get involved in building a truly innovative open source tactical radio service by visiting https://ribbitradio.org

Join Ribbit mailing lists at: https://www.openresearch.institute/mailing-lists/

Amateur Satellite: ORI has the world’s first and only open source HEO/GEO communications satellite program, called Haifuraiya. We will demonstrate all working parts of the transponder project at DEFCON 31, where broadband digital communications and open source electric propulsion will be featured. Find out how to support or join this and other teams at https://openresearch.institute/getting-started

AmbaSat for 70 cm: We’ve redesigned the AmbaSat board to move it from 915 MHz to 70 cm and it will be flown on a sounding rocket this year. With increasing interest in LoRa for both space and terrestrial use, this has proven to be a popular and useful project. The design has been adapted for applications in India and Japan.

Opulent Voice: a digital protocol that seamlessly combines high fidelity voice and data, using modern forward error correction, authentication and authorization, and efficient minimum frequency shift keying modulation. Opulent Voice will be flown on a sounding rocket this year and it is the native digital uplink protocol for Haifuraiya. Completely open with the high quality voice we deserve to hear. Due to the bandwidth requirements of the 16kHz OPUS codec, Opulent Voice can be used on 70cm and above ham bands, or anywhere else where the modest bandwidth requirements can be met.

Remote Labs: We have two remotely accessible workbenches for FPGA development, with Xilinx 7000 and Xilinx Ultrascale+ development boards as the focus. We also have several SDRs and radio utility devices available through virtual machine access. The 7000 series development board has an Analog Devices ADRV9371 radio system attached, and that has enabled a number of open source FPGA products to be published. This is a unique resource that has produced a lot of good work and is constantly being improved and updated. In addition to the development boards, the laboratory has a network accessible spectrum analyzer, an oscilloscope with logic analyzer extension, power supplies, frequency and power counters, and dedicated human resources available to help students, volunteers, or professionals contribute to open source work. Help it be more useful by spreading the word about ORI Remote Labs.

Equipment available: https://github.com/phase4ground/documents/tree/master/Remote_Labs/Test_Equipment
How to get an account: https://github.com/phase4ground/documents/blob/master/Remote_Labs/ORI-New-User-Setup.md
Using FPGA Development Stations: https://github.com/phase4ground/documents/blob/master/Remote_Labs/Working-With-FPGAs.md

Versatune: amateur digital television next generation hardware and software product. It is open source and affordable. We have committed engineering resources to support Versatune and are very excited about how things are going. Some of the Versatune team will be at Hamvention 2023 in Xenia, OH, USA, and it will be represented at DEFCON in August 2023.

HF antennas: We have a novel foldable antenna design for space and terrestrial use. The hardware prototype will be demonstrated at DEFCON. This design manipulates radiation resistance to produce best-of-class results. Think you can’t do 160m without an enormous antenna? Think again.

HF QRP: Coming soon, an exciting HF QRP digital radio board and protocol. The hardware prototypes will be demonstrated at DEFCON. What might happen when we combine the HF digital radio with the novel foldable antenna? We think you’ll be delighted.

Battery Matching Curves: are you available to mentor a college student interested in learning how to match up charge and discharge curves from NiCd cells in order to create battery packs? These packs would then be tested and/or deployed in the field. Our student volunteer has collected the data and is looking to learn how to use Jupyter Notebooks to select the cells to create battery packs.

Logistics

We’re growing and adapting!

We will be changing our GitHub project name from Phase4Ground to Open Research Institute very soon. Phase4Space GitHub project will change to Haifuraiya, which is the program name for our HEO/GEO design. These changes better reflect the content and purpose of the 64 repositories that span everything from important historical archives to open source music to the most modern open source encoders available.

We have a very well-qualified applicant for our open board of directors position. We would like to invite interested community members to consider applying to ORI in order to expand the board beyond this filled position in order to take us from our current five members to seven. Given our continuing growth, a larger leadership team would ensure continued smooth operations. These positions are unpaid, engaging, and can be demanding. The most important skill set is a strong sense of ethics and service.

Fundraising and Grants

We’ve applied for the GitHub Accelerator Program (Remote Labs) and the IEEE Innovation Fund (Polar Codes in Ribbit). If you have a recommendation for ORI in terms of partnerships or collaboration, please let us know at hello@openresearch.institute

Support ORI financially directly through the website https://openresearch.institute. There is a PayPal donation widget at the bottom of almost every page. Donations can be directed to any project, or to general operations. ORI has a very low overhead, with most projects coming in under 5%.

Support our open source propulsion work and get a cool desk toy at https://us.commitchange.com/ca/san-diego/open-research-institute/campaigns/where-will-we-go-next

We’ve raised enough money to cover materials for machining the engine parts. The next step is to raise enough money to pay for the electronics. Please help spread the word!

Thanks to our wonderful community, we have employee matching in place at Microsoft and Qualcomm. If you have an employee matching program at your work, and you think ORI would fit in, please consider nominating us. Our EIN is EIN: 82-3945232

Events

Where can you meet up with ORI people?

QSO Today Ham Expo

We support and attend QSO Today Ham Expo, held online 25-26 March 2023. The theme of this event is “New License, Now What?” and focuses on people new to amateur radio.

Our page for QSO Today Ham Expo content is https://www.openresearch.institute/qso-today-ham-expo-technical-demonstrations/

IMS2023

Join us at the amateur radio social at the International Microwave Symposium (IMS2023) on Tuesday 13 June 2023 in San Diego, CA, USA at 6pm. It will be held in a beautiful outdoor venue with food and drink provided. The easiest way to register for this event is to purchase an exhibition badge and then sign up for the social. https://ims-ieee.org/ is the event website.

DEFCON

We are getting ready for our biggest event of the year. We have proposed an in-person Open Source Showcase to RF Village for DEFCON 31 in Las Vegas, Nevada, USA from 10 – 13 August 2023.

Our page for the event, with all the latest and greatest details, can be found at https://www.openresearch.institute/defcon/

Want to help at DEFCON? Please visit https://openresearch.institute/getting-started and let us know!

IWRC 2023

IEEE wants to bring together all participants to take full advantage of CHIPS Act funding. IEEE will have an Innovative Workforce Resources Conference in Little Rock, AR 13-14 September. There will be a reception at the Clinton Presidential Library, and attendees will enjoy the best BBQ in the country. The National Science Foundation requires that a certain percentage of funding has to be spent in states that don’t get their fair share of research money. The goal of this conference is to pull together small researchers from small business like ORI and do research, with Arkansas as a focus.

We couldn’t agree more. After all, we are putting a lot of time and energy into Remote Labs South, located just outside Little Rock, AR. Bringing innovative open source digital radio work to students, workers, and volunteers that need it the most simply makes sense. If you can attend IWRC 2023 and help represent ORI please get in touch. We will be reaching out to IEEE chapters in Arkansas as well.

Read about the CHIPS and Science Act here: https://en.wikipedia.org/wiki/CHIPS_and_Science_Act

Puzzle Solution

43 is the largest number of nuggets that cannot be ordered.

What is the largest number of McNuggets that you can’t buy with packs of 6, 9 and 20? After putting in their blood, sweat, and tears, the mathematicians found that the answer is 43. You cannot buy 43 nuggets with packs of 6, 9 and 20, but you can buy any amount larger than 43.

Please see Mike Beneshan’s excellent blog about this type of problem at https://mikebeneschan.medium.com/the-chicken-mcnugget-theorem-explained-2daca6fbbe1e

The other Non-McNugget numbers are 1,2,3,4,5,7,8,10,11,13,14,16,17,19,22,23,25,28,31,34, and 37.

Trivia: You can get 47 in two ways: 36+19+120 or 06+39+120.

We’ve used the McDonald’s version of the chicken nugget to present and frame this mathematical puzzle. Here’s a link about the history of this menu item: https://www.thrillist.com/news/nation/history-of-chicken-mcnuggets

Robert C. Baker invented the chicken nugget, among many other things. He was a true innovator of what can be fairly called “modern foods”. A brief wikipedia article about him can be found here: https://en.wikipedia.org/wiki/Robert_C._Baker

A song written about this remarkable inventor can be enjoyed at this link: https://youtu.be/OEa8wqv4QM0

Do you have an idea for an interdisciplinary puzzle for our next newsletter? We’d love to hear about it. Write ori@openresearch.institute

Until Next Time

Thank you so much for being part of our Inner Circle! You are the motivation for all of this work, provided to the general public for free. We believe it makes the world a better place.

Inner Circle – September 2022

Greetings from Open Research Institute!

We hope to see you again at QSO Today Ham Expo this weekend, 17-18 September 2022. We have a booth, five talks, three project exhibits, and a lounge space for meet and greet.

To find out more about Ham Expo, visit https://www.qsotodayhamexpo.com/

Since the last Ham Expo, we’ve integrated the DVB-S2/X encoder into the downlink reference design for our open source broadband microwave transponder. We have started on the uplink receiver. We have published a specification for our high bitrate digital voice and data uplink protocol. It’s called Opulent Voice and it will be introduced and described at the Expo. Find the source code for a C++ implementation at https://github.com/phase4ground/opv-cxx-demod

We have two sounding rocket projects, an open source propulsion project, successful regulatory work, and we represent open source and amateur radio interests on the US FCC Technological Advisory Committee. We co-chair the “Safe Uses of AI/ML” subworking group.

Our open source HEO proposal Haifuraiya will be presented at the Expo this weekend and details will be in an upcoming JAMSAT Journal.

We do terrestrial communications as well! Ribbit is a digital emergency communications mode for VHF/UHF. No extra equipment or cables required. We have a poster about the project in the exhibit hall and a presentation. Get the free Android application at https://play.google.com/store/apps/details?id=com.aicodix.rattlegram

All video presentations will be available at our YouTube channel after the Ham Expo platform has closed in 30 days.

We have a mailing list for updates and discussion, a Slack account for engineering work, and all work is published as it is created to our GitHub account.

To join any of these resources at ORI, please visit https://www.openresearch.institute/getting-started/

If you’d like to get monthly newsletters like this one, then do nothing. You’re already part of the inner circle!

Our volunteers could not accomplish all of this wonderful work without your interest and support.

Thank you from everyone at ORI. We value your comment, critique, and feedback, and look forward to hearing from you. If you use social media, then a lot of what we do is published through the channels linked below.

Thank you from all of us at ORI!

QR code for Open Research Institute's newsletter signup form at http://eepurl.com/h_hYzL
Sign up for the newsletter

Subscribe to ORI’s “Inner Circle” Newsletter

Join the Inner Circle at ORI.

ORI publishes a lot of technical reports. There’s over 30 repositories, 10 projects, and well – that’s a lot to digest. People asked for something easier to read that came less often so we did just that.

The link is http://eepurl.com/h_hYzL and the QR Code is below.

The response to the newsletter has been really nice with over 2000 subscribers in the first two weeks. Please consider yourself invited!

ORI is a non-profit all-volunteer group that donates all of its work to the amateur radio and amateur radio satellite services. Subscriber information is private and will not ever be sold.

QR code for Open Research Institute's newsletter signup form at http://eepurl.com/h_hYzL