The European Space Agency has a Call for Proposals concerning Geostationary Amateur Payloads. We have contributed a technical support package and communicated our standalone HEO/GEO design to the ESA.
Thank you to all the volunteers that have contributed towards this achievement.
Opportunities This Week at ORI
Greetings all!
What do you need help with this week?
Here’s some opportunities at ORI.
1) Pierre and Ahmet are looking for people to help with mobile app design on Ribbit.
The Ribbit Radio app is in both Android and Apple testing. The updates to Rattlegram are incorporated and the app is functional on both platforms. We have had excellent response for test teams and things are moving forward.
To make the app as great as it can be, we could use some additional human resources for UX/UI/code development. If this sounds like something you are interested in, please join #ribbit on our Slack or write to me directly and I’ll get you in touch with the team leads.
2) DEFCON volunteers for the booth/exhibit. We’ve got just enough people to cover it. It’s a great event. We have solid support from RF Village and we advertise to Ham Radio Village. If you have been sitting on the sidelines waiting for a chance to do something for ORI, this is the best event of the year.
https://defcon.org/ for details about DEFCON 10-13 August 2023
https://wirelessvillage.ninja/ for details about our Village, RF Hackers Sanctuary.
3) FPGA designs for Haifuraiya and Neptune. Want to use MATLAB/Simulink, VHDL, and Verilog to make open source digital communications designs for aerospace, terrestrial, and drones? These designs run on updated FPGA stations in ORI Remote Labs, and everything is on the microwave amateur radio bands. When you see microwave frequencies mentioned, then it’s good to also say that “we use these bands or lose them”. We’ve got plenty to do. Get in touch on #haifuraiya or #neptune on Slack or to any ORI director.
4) Meander Dipole construction phase. Project Dumbbell explores an overlooked HF antenna design. There’s been strong interest in these designs from multiple people (some of which are on this list), clubs, and organizations. We need to build the designs that MATLAB says look pretty good. Time to make it work over the air and write up some construction and measured performance articles.
As always, there’s plenty more going on, but these projects have some specific needs, today.
Thank you to everyone that supports our work. I’d like to especially thank the IEEE and ARRL for being excellent partners to ORI.
-Michelle Thompson
Updating the Opulent Voice Interleaver
The interleaver for Opulent Voice needs to be updated because the frame size has increased. We are incorporating RTP, UDP, and IP layers into the existing OPUS and 4-ary MFSK layers and now have what we think may be the final frame size.
Since convolutional encoding is used for Opulent Voice payload, an interleaver is necessary to get the best bit error rate performance out of the convolutional encoder. The interleaver is used over both the physical layer header (Golay encoded) and the data payload (a 1/2 rate Convolutional code). Opulent Voice is an open protocol that we use for our HEO/GEO uplink. It can also be used terrestrially on the #hamradio bands at 70cm and above. Find out more at https://www.openresearch.institute/2022/07/30/opulent-voice-digital-voice-and-data-protocol-update/
The distance that an interleaver spreads out bits in a frame is the most familiar performance measurement. It’s commonly called “spread” or “minimum interleaved distance”. However, we learned about another metric that is important in Turbo codes. Several papers refer to the measure of randomness of the mixture of bit position reassignments as “dispersion” (for example, see https://cgi.tu-harburg.de/~c00e8lit/cgi-bin/ivpub/download.php?file=kb-wpmc2008.pdf). That particular paper cited another paper (reference [6]) as defining dispersion.
Following that citation lead to a paper but this paper didn’t mention dispersion or explain the equation. Going back to the original paper, we started working with the definition for dispersion that we had. This used the cardinality of the set of indices of original bit positions vs. permuted bit positions. This seemed straightforward enough. But, after trying this in MATLAB, we always got the minimum dispersion value, so there must be something wrong with our interpretation.
Volunteers then spent time trying to figure out if dispersion is important enough metric for a single convolutional code, like we have in #OpulentVoice. In other words, should we simply not simply choose the polynomials that result in the largest minimum interleaved distance? Selecting the right interleaver based on a balance between how far apart it spreads the bits vs. how randomly the bits are distributed is a useful selection methodology for Turbo codes, but may not be strictly necessary for a single convolutional code used with 40 mS frames.
Everyone is welcome to join in the discussion and work to create quality #OpenSource work for #digital communications at ORI. Please see https://openresearch.institute/getting-started to be welcomed to our community.
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.
QoS: Call for Input
We’re moving into the challenge of multiplexing on the transponder with a goal of delivering Quality of Service (QoS) metrics and policies.
This is “how do the uplink packets get properly prioritized on the downlink, to make the most of limited resources”.
These resources are spectrum, power, and time.
QoS doesn’t make any of our communications channels go faster. This is a common misconception about QoS. Here’s some descriptions from conversations this week. I would like to hear more opinions about QoS in general, and any specific requirements that people on this list might have.
Kenneth Finnegan writes,
“In #networking it’s common to forget that QoS is mainly about deciding which packets you’d rather drop first.
If you don’t like that idea, then you just need to pony up and throw more capacity at the problem.”
Adam Thompson continues,
“In the presence of a pizza that’s not big enough for all the hungry people, QoS inhibits less-important pizza eaters. This lets more-important eaters-of-pizza get more pizza than their fair share, at the expense of the less-important eaters.
“In the presence of a pizza that’s not big enough for all the hungry people, QoS inhibits less-important pizza eaters. This lets more-important eaters-of-pizza get more pizza than their fair share, at the expense of the less-important eaters.
QoS never (ever!) makes the pizza bigger – if you need more pizza, you must still bake or buy more, or someone’s going to go hungry!
Complex QoS systems might let you differentiate between e.g. crust and topping and permit cutting the pizza into bizarre topographies/topologies, but still can’t make the pizza any bigger.
Finally, if there is enough pizza for everyone, QoS doesn’t do anything useful.”
If this last part sounds familiar, then you’re not alone. QoS often doesn’t do anything useful… in a resource rich environment. This may be the main reason that we sometimes hear that QoS is a “failure”, that it’s “never used”, or “why bother for hams since hams don’t care about this subject at all”.
It is true that most amateur communications are made with acres and acres of spectrum, with a very generous power limit (although you are supposed to use the minimum required power) and no time limits on how often you can try to make a contact.
When we talk about microwave broadband digital communications, it’s a different situation. And, with space channels, there are constraints. We have less bandwidth to work with because we’re on a sub-band. We have latency, which is non-trivial for GEO or beyond. We have power concerns and pointing requirements.
“Adaptive” QoS that does nothing until congestion forces some decisions, at which time we sort with respect to SNR, has been our baseline.
What we want to do when constraints are hit is what we need to better define. Right now, we have a whiteboard design (summarized above) and a paper about Adaptive Coding and Modulation (ACM) that was published in AMSAT-DL and AMSAT-UK Journals.
We have the implementation guidelines from GSE as well, which address QoS and show how to set up queues.
With a controllable downlink going out over the air, and a defined uplink protocol, now is the time to work on exactly how to multiplex the traffic. Evariste asked about this exact thing less than a week ago at the FPGA meetup.
Decisions about QOS heavily affect the central part of the design, so let’s get this right.
Do you have experience implementing QoS policies? Do you have experience with bad QoS policies as a consumer? Do you have an idea about what you want to see this design do?
Well, you’re in the right place, and we’d love to hear what you have to say about it.
Participate at https://openresearch.institute/getting-started
AI vs. Human: ChatGPT vs. ORI Open Source Designers
Greetings all,
You know that ORI has been active in a variety of regulatory work for several years now. One of those areas has been in AI/ML and the effect on communications. We served on the US FCC TAC in 2022, have presented and written on the subject, and are working towards an AI/ML Handbook for Amateur Radio.
You may have seen news about OpenAI GPT, or ChatGPT.
https://openai.com/api/
There’s a lot of people testing this chatbot out for reverse engineering and in writing software. There’s been some successes in cases where the model would have had access to code or documentation about protocols, observations, or technical behavior in order to train, and requests match up well with the models.
For example, a friend asked the chatbot to create a Python script to access the webcam on their computer, and they shared a still image from the resulting feed. Another example from another friend resulted in better reverse engineering results than they had gotten with either IDA or Ghidra over many weeks.
So, how does ChatGPT handle VHDL?
We have something specific to compare against, since we just completed a COBS decoder in VHDL for our open source HEO/GEO transponder work for #Haifuraiya.
Let’s start off simple. Here’s the first dialogue with the chatbot, and the results.
-=-=-=-=-=-=-=-=-=-=-=-=-=-
Abraxas3d: Design a COBS decoder in VHDL
Sure, here’s an example of a COBS decoder in VHDL:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;entity COBS_decoder is
Port (
input_data : in std_logic_vector;
decoded_data : out std_logic_vector
);
end COBS_decoder;architecture Behavioral of COBS_decoder is
— Declare a variable to keep track of the current index
— in the input and output data streams
variable current_index : integer := 1;
— Declare a variable to store the length of the
— run of zeros in the input data
variable zero_run_length : integer := 0;
begin
— Iterate over the input data
for i in input_data’range loop
— If the current input value is a zero, increment
— the zero run length variable
if input_data(i) = ‘0’ then
zero_run_length := zero_run_length + 1;
— Otherwise, the current input value is not a zero,
— so we’ve reached the end of the zero run
else
— Set the decoded value at the current index to
— the length of the zero run
decoded_data(current_index) := conv_std_logic_vector(zero_run_length, 8);
— Increment the current index and reset the zero
— run length for the next iteration
current_index := current_index + 1;
zero_run_length := 0;
end if;
end loop;
end Behavioral;
This code decodes the input data using the COBS (Consistent Overhead Byte Stuffing) algorithm, which involves replacing runs of zeros in the input data with a single byte that indicates the length of the zero run. For example, the input ‘101001000’ would be decoded as ‘103101’.
This decoder iterates over the input data and maintains a variable zero_run_length that is incremented for each zero in the input data. When a non-zero value is encountered, the length of the zero run is written to the output data and the zero_run_length variable is reset.
I hope this helps! Let me know if you have any other questions.”
-=-=-=-=-=-=-=-=-=-=-=-=-=-
It knew what COBS meant. It produced code, with comments, and a brief “design document”, with examples.
The code produced is not licensed or cited.
Our open source HEO transponder project uses AXI-based blocks in the FPGA. So, let’s add AXI to the request.
-=-=-=-=-=-=-=-=-=-=-=-=-=-
Abraxas3d: Design a COBS decoder with AXI interface in VHDL
Sure, here’s an example of a COBS decoder with an AXI interface in VHDL:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;— AXI interface definitions
library unisim;
use unisim.vcomponents.all;entity COBS_decoder is
Port (
AXI_IN : in AXI4Stream;
AXI_OUT : out AXI4Stream
);
end COBS_decoder;architecture Behavioral of COBS_decoder is
— Declare a variable to keep track of the current index
— in the input and output data streams
variable current_index : integer := 1;
— Declare a variable to store the length of the
— run of zeros in the input data
variable zero_run_length : integer := 0;
begin
— Iterate over the input data
for i in AXI_IN.data’range loop
— If the current input value is a zero, increment
— the zero run length variable
if AXI_IN.data(i) = ‘0’ then
zero_run_length := zero_run_length + 1;
— Otherwise, the current input value is not a zero,
— so we’ve reached the end of the zero run
else
— Set the decoded value at the current index to
— the length of the zero run
AXI_OUT.data(current_index) := conv_std_logic_vector(zero_run_length, 8);
— Increment the current index and reset the zero
— run length for the next iteration
current_index := current_index + 1;
zero_run_length := 0;
end if;
end loop;
— Set the valid and last flags in the output AXI stream
AXI_OUT.valid <= ‘1’;
AXI_OUT.last <= ‘1’;
end Behavioral;
This code is similar to the previous example, but it uses an AXI (Advanced eXtensible Interface) interface for the input and output data. The AXI interface is a standard interface used in many FPGA designs, and it provides a way to stream data into and out of the decoder.
In this code, the input data is read from the AXI_IN.data port, and the decoded output is written to the AXI_OUT.data port. The valid and last flags are also set in the output AXI stream to indicate that the data is valid and that it is the last data in the stream.
I hope this helps! Let me know if you have any other questions.
-=-=-=-=-=-=-=-=-=-=-=-=-=-
It knows about the previous request and updated the design. No license.
Here’s a review of the COBS implementation from Paul Williamson KB5MU.
“I don’t know what this is, but it isn’t a COBS decoder with AXI interfaces.
It does seem at first glance to be some sort of thing with AXI interfaces, but it does not implement an AXI interface at all. It just relies on a (possibly imaginary) library type called AXI4Stream that somehow magically does AXI interfaces, in a way that’s both implausibly smart and inexplicably dumb. I think the classic phrase “not even wrong” applies here.
The AXI4Stream object apparently has a member .data that is an array of bytes, which might make sense if the entire AXI transfer is being treated as a single entity here. The code iterates through the input .data using the ’range attribute, as if the AXI4Stream object has a defined fixed transfer length.
Which it can’t have, if it’s a general purpose AXI stream implementation.
So, if this was ever anything real, it must have been a special purpose AXI implementation with a fixed transfer length. Assuming that the AXI4Stream .data actually works that way, the entity does
do some sort of transformation on the input data to create the output data.
We asked for that to be a COBS decoder, but the function that it actually implements bears only the slightest resemblance to a COBS decoder. What it actually does is output a stream of words that are the lengths of the runs of zeroes in the input data. Nonzero data does not get passed through at all.
Instead, a run of nonzero bytes gets translated into a run of zeroes, as if two adjacent nonzero bytes meant nothing but a zero-length run of zeroes.
Here’s an example of what this code seems to do:
Input .data: 1 2 3 4 0 0 0 0 1 2 3 4
Output .data: 0 0 0 0 4 0 0 0That’s certainly not a COBS decoder, or even anything useful at all.
Note that the output is variable length, but never longer than the input.
We had to assume that the AXI4Stream object had a fixed .data size to get this far, but now it has to have a variable data size for the output.
Supposing we had successfully suspended disbelief up to here, we now examine the final two lines of code in the Behavioral architecture. It sets the .valid and .last members of the AXI_OUT port to ‘1’.
That makes absolutely no sense if it’s supposed to encapsulate an entire AXI stream transfer. Those signals only make sense if we’re treating one word at a time, as you’d expect to see in a normal, general-purpose AXI stream object.
The extremely verbose commenting style in this code suggests that the original source material was from an introductory tutorial. Maybe the AI has been tuned to favor heavily commented code, and ends up picking up partially completed junk from the middle of tutorials?
Anyhow, this is not an example of automated programming in response to a high-level query. This is gibberish that succeeds only in having a superficial resemblance to the code requested.”
So, does this work?
Let’s try it out in the lab!
The first thing we notice is that there is an obvious syntax error with a missing semicolon. Aside from that, there is no AXI4Stream port type. It’s not recognized. Vivado appears to be disappointed in this file, and wants little to do with this code. This is where we should stop, but I spent some time looking to see if the ports were at least close to being declared correctly.
The model appears to have taken some custom or maybe enumerated type from somewhere, and come up with a custom AXI4Stream type. This is not recognized by the unisim library right off the bat, and that’s the sort of thing that automated code writing needs to get right.
Let’s look at the code written by humans from ORI. The decoder can be found here:
https://github.com/Abraxas3d/fpga_cores/blob/master/src/decoder.vhd
-=-=-=-=-=-=-=-=-=-=-=-=-=-
— Company: Open Research Institute, Inc.
— Engineer: Skunkwrx, Abraxas3d
— Design Name: COBS protocol decoder
— Module Name: decoder – Behavioral
— Project Name: Phase 4 “Haifuraiya”
— Target Devices: 7000 Zynq
— Tool Versions: 2021.1
— Description: COBS protocol decoder.
— Additional Comments: This work is Open Source and licensed using CERN OHL v2.0
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
–Entity Declaration
entity decoder is
Port ( rst : in STD_LOGIC;
clk : in STD_LOGIC;
s_tdata : in STD_LOGIC_VECTOR (7 downto 0);
s_tlast : in STD_LOGIC;
s_tvalid : in STD_LOGIC;
s_tready : out STD_LOGIC;
m_tdata : out STD_LOGIC_VECTOR (7 downto 0);
m_tlast : out STD_LOGIC;
m_tvalid : out STD_LOGIC;
m_tready : in STD_LOGIC);
end decoder;
–Architecture
architecture Behavioral of decoder is
— internal copy of s_tdata
signal input_data : STD_LOGIC_VECTOR (7 downto 0);
— s_tdata delayed by one clk where s_tvalid is high
signal input_data_d : STD_LOGIC_VECTOR (7 downto 0);
— internal version of s_tlast
— not used for anything
— We create our own m_tlast from the COBS framing instead
signal s_tlast_i : STD_LOGIC;
— internal version of input handshaking signal s_tvalid
signal s_tvalid_i : STD_LOGIC;
— s_tvalid delayed by one clk
— thus, a version of s_tvalid aligned with input_data_d
signal s_tvalid_i_d : STD_LOGIC;
— s_tvalid delayed by two clks
— thus, a version of s_tvalid aligned with output_data
signal s_tvalid_i_d_d : STD_LOGIC;
— countdown of bytes in this sequence
— loads from input_data_d when it represents the frame count
— as determined by signal counter_load
— contains the count while m_tdata contains the implied 0 at
— the end of a sequence, or the next count that replaced it
— counts down thereafter, to contain 1 when the last non-zero
— byte of the sequence is on m_tdata
— allowed to count down to 0, but not beyond
signal count : STD_LOGIC_VECTOR (7 downto 0);
— enable to load count from input_data_d on this clk edge
— two cases detected:
— * first valid non-zero byte after a frame separator
— * first valid byte after count is exhausted
— allowed to be high for multiple cycles
signal counter_load : STD_LOGIC;
— counter_load delayed by one clk where s_tvalid is high
— used to identify the first valid data byte of any sequence,
— for purposes of computing m_tvalid (via pre_tvalid)
signal counter_load_d : STD_LOGIC;
— detection of a valid frame separator (zero) byte in input_data_d
signal frame_sep : STD_LOGIC;
— frame_sep delayed by one clk where s_tvalid is high
— used to compute counter_load
— used to compute rising edge of pre_tvalid
signal frame_sep_d : STD_LOGIC;
— frame_sep_d delayed by an additional clk (not depending on s_tvalid)
— used to find the first non-zero byte of the new frame
signal frame_sep_d_d : STD_LOGIC;
— move the frame_sep signal that occurred during m_tready low
— out to the first cycle when m_tready is high again
signal use_saved_frame_sep : STD_LOGIC;
— flag to remember that the frame count for this sequence was 255,
— to handle the special case that such a sequence does not have
— an implied zero byte at the end.
— set when loading count with 255
— cleared when the counter is reloaded with anything else
signal case_255 : STD_LOGIC;
— internal version of m_tdata output
signal output_data : STD_LOGIC_VECTOR (7 downto 0);
— internal version of m_tlast output
— high when the last byte of a frame is valid on m_tdata
signal m_tlast_i : STD_LOGIC;
— delayed versions of m_tlast
signal m_tlast_i_d : STD_LOGIC;
signal m_tlast_i_d_d : STD_LOGIC;
— intermediate result for m_tvalid.
— high across all data bytes of each sequence on m_tdata
— does not go low for bytes on m_tdata corresponding to
— bytes invalidated by s_tvalid.
signal pre_tvalid : STD_LOGIC;
— internal version of m_tvalid output.
— pre_tvalid with periods of low s_tvalid_d_d punched out
signal m_tvalid_i : STD_LOGIC;
— internal version of m_tready input
— also the internal version of s_tready output
— passes through m_tready to s_tready with no clk delays
signal m_tready_i : STD_LOGIC;
— constant byte value 0xFF, for comparison purposes
signal all_ones : STD_LOGIC_VECTOR(input_data’range) := (others => ‘1’);
— constant byte value 0x00, for comparison purposes
signal all_zeros : STD_LOGIC_VECTOR(input_data’range) := (others => ‘0’);
begin
— asynchronous assignments
frame_sep <= ‘1’ when input_data_d = all_zeros and s_tvalid_i_d = ‘1’
else ‘0’;
m_tlast_i <= ‘1’ when ((frame_sep = ‘1’ and m_tvalid_i = ‘1’ and m_tready = ‘1’))
else ‘0’;
counter_load <= ‘1’ when (input_data_d /= all_zeros and frame_sep_d = ‘1’ and s_tvalid_i_d = ‘1’) — start of frame
or (to_integer(unsigned(count)) = 1 and s_tvalid_i_d = ‘1’) — start of next sequence in frame
else ‘0’;
m_tvalid_i <= ‘1’ when ((pre_tvalid = ‘1’ and s_tvalid_i_d_d = ‘1’ — usual case, if input_data was valid
and not (to_integer(unsigned(count)) = 1 and s_tvalid_i_d = ‘0’)) — defer last byte; might be m_tlast
or (pre_tvalid = ‘1’ and to_integer(unsigned(count)) = 1
and s_tvalid_i_d = ‘1’ and s_tvalid_i_d_d = ‘0’)) — pick up that deferred last byte
else ‘0’;
s_tready <= m_tready_i;
m_tdata <= output_data;
input_data <= s_tdata;
s_tvalid_i <= s_tvalid;
m_tready_i <= m_tready;
m_tvalid <= m_tvalid_i;
m_tlast <= m_tlast_i;
— processes
set_case_255 : process (rst, clk)
begin
if rst = ‘1’ then
case_255 <= ‘0’;
elsif rising_edge(clk) and m_tready_i = ‘1’ then
if counter_load = ‘1’ and input_data_d = all_ones then
case_255 <= ‘1’;
elsif counter_load = ‘1’ and input_data_d /= all_ones then
case_255 <= ‘0’;
end if;
end if;
end process set_case_255;
delay_s_tvalid : process (rst, clk)
begin
if rst = ‘1’ then
s_tvalid_i_d <= ‘0’;
s_tvalid_i_d_d <= ‘0’;
elsif rising_edge(clk) and m_tready_i = ‘1’ then
s_tvalid_i_d <= s_tvalid_i;
s_tvalid_i_d_d <= s_tvalid_i_d;
end if;
end process delay_s_tvalid;
create_pre_tvalid : process (rst, clk)
begin
if rst = ‘1’ then
counter_load_d <= ‘0’;
pre_tvalid <= ‘0’;
elsif rising_edge(clk) and m_tready_i = ‘1’ then
if s_tvalid_i_d = ‘1’ then
counter_load_d <= counter_load;
if (frame_sep_d_d = ‘1’ and frame_sep_d = ‘0’) — normal last byte of frame
or (counter_load_d = ‘1’ and frame_sep_d = ‘0’) — normal first byte of a sequence
then
pre_tvalid <= ‘1’;
end if;
end if;
if frame_sep = ‘1’
then
pre_tvalid <= ‘0’;
end if;
if counter_load = ‘1’ and case_255 = ‘1’ then
pre_tvalid <= ‘0’;
end if;
end if;
end process create_pre_tvalid;
delay_m_tlast_i : process (rst, clk)
begin
if rst = ‘1’ then
m_tlast_i_d <= ‘0’;
m_tlast_i_d_d <= ‘0’;
elsif rising_edge(clk) and m_tready_i = ‘1’ then
m_tlast_i_d <= m_tlast_i;
m_tlast_i_d_d <= m_tlast_i_d;
end if;
end process delay_m_tlast_i;
set_counter : process (rst,clk)
begin
if rst = ‘1’ then
count <= (others => ‘0’);
frame_sep_d <= ‘0’; frame_sep_d_d <= ‘0’; elsif rising_edge(clk) and m_tready_i = ‘1’ then frame_sep_d_d <= frame_sep_d; if s_tvalid_i_d = ‘1’ then frame_sep_d <= frame_sep; if counter_load = ‘1’ then count <= input_data_d; elsif count /= all_zeros then count <= STD_LOGIC_VECTOR(unsigned(count) – 1); end if; end if; end if; end process set_counter; create_output : process (rst, clk) begin if rst = ‘1’ then output_data <= (others => ‘0’);
elsif rising_edge(clk) and m_tready_i = ‘1’ then
if counter_load = ‘1’
then
output_data <= all_zeros;
elsif s_tvalid_i_d = ‘1’ then
output_data <= input_data_d;
end if;
end if;
end process create_output;
selective_delay_of_input_data : process (rst,clk)
begin
if rst = ‘1’ then
input_data_d <= all_zeros;
elsif rising_edge(clk) and m_tready_i = ‘1’ then
if s_tvalid_i = ‘1’ then
input_data_d <= input_data;
end if;
end if;
end process selective_delay_of_input_data;
end Behavioral;
-=-=-=-=-=-=-=-=-=-=-=-=-=-
This codebase doesn’t include just the source code, but also a testbench file, a design document, timing diagrams, a Python notebook that creates test vectors, and Python code that compares results produced by the testbench that uses the test vectors.
None of this sort of thing is produced by ChatGPT.
There is code in some languages for some functions that can be correctly written by AI at this point.
This is a situation similar to algorithmic musical composition. Algorithms can come up with useful ideas, motifs, sketches, or traverse a search space more quickly than a human. They can help a composer, but do not replace one. Algorithms can produce some sparkling gems of ideas. These are fresh cuts and views. This is mixed in with a lot of music that is just plain wrong.
If your programming job happens to be in a well-defined area that is easily automated, then you do have something to worry about today.
All jobs are a target for eventual automation with AI/ML. Yes, all of them. As AI/ML becomes more capable, it will automate even things like testbench writing (HDL Coder already does something like this) and support code (like a Python notebook that creates a solid set of test vectors for a testbench) and design documents. All of us should be aware of what we do being replaced by an algorithm some number of tomorrows in the future.
That day is not yet “today” with Chat GPT, when it comes to writing #VHDL.
What do you think? We’re interested in your experience and opinions with AI/ML writing code.
September 2022 QSO Today Ham Expo – ORI’s Open Source Technical Presentations
These are our technical talks from the September 2022 QSO Today Ham Expo.
Thank you to everyone that supports our work ❤️
Deviation Limits of the MD-380
Not enough deviation for Opulent Voice
We measured the deviation limits on the MD-380 with firmware from OpenRTX. Thank you to Redman for help with modifying the firmware to make this test as easy as possible.
The transmitted signal is about 10 dB down at 3000 Hz and almost gone at 4200 Hz. Therefore, there is not enough deviation for Opulent Voice.
The part of the radio under test was the HR_C5000. This is a part from Hong Rui and is a DMR digital communications chip. The chip handles 4FSK modulation and demodulation, among other functions.
According to a translated datasheet for the HR C5000, adjustment of the frequency offset range not possible. It appears to be designed only for +/- 3 kHz. Unless there’s an undocumented feature, or gain is added after the HR C5000, then +/- 3 kHz is the maximum deviation for this radio.
The HR C5000 puts out two analog signals MOD1 and MOD2, which are combined and then drive a varactor diode. The varactor might well have more range. Or it could be replaced with one that has more range.
Below is a photo essay of the testing and screenshots of results.
Test Results
It would not be an issue in the original design, with all audio coupled through capacitors. No way anything that close to DC would get to the audio chip.
How Can Open Research Institute Help *You*?
Thank you so much for visiting with us at QSO Today Ham Expo! We hope you found it as enjoyable, vibrant, and inspiring as we did.
We presented five talks, had three project exhibits, and a booth. You can find a summary below.
Your interest in our work is appreciated. We want you to enjoy open source non-profit digital radio and amateur radio to the fullest. How can we help?
Here is how to get involved with what we do:
https://www.openresearch.institute/getting-started/
Here’s a roundup of what we brought to Ham Expo. All of what we do is published as it is created. Our work is free to the general public at no cost.
-=-=-=-=-=-=-=-=-=-
Ribbit, a new digital text messaging mode for UHF/VHF emergency communications
Presentors: Pierre Deliou W4CKX, Ahmet Inan
Level: General Audience Category: Emergency Communications Time:
PDT: September 18, 2022, 10:00 am UTC: September 18, 2022, 5:00 pm
Ribbit is a novel digital text messaging mode for VHF/UHF communications for recreational and emergency use which radically increases the density of information transmitted by spectrum used. It leverages the computing power of the modern smartphone to increase the capabilities of any Handy Talkie without requiring any additional hardware. Its redundant distributed nature allows it to function even when connectivity to the internet is lost during emergencies. Ribbit is open source and currently in its early stages of development. Get the free Android app here: https://play.google.com/store/apps/details?id=com.aicodix.rattlegram
Artificial Intelligence and Machine Learning and the Future of Amateur Radio
Level: Intermediate Category: DSP and Software Design, Future of Amateur Radio, SDR Software Defined Radio, Software and Services Time:
PDT: September 17, 2022, 1:00 pm UTC: September 17, 2022, 8:00 pm
Artificial Intelligence and Machine Learning are all over the news, taking over academia, getting billions of dollars of commercial investment, and will change both computer networking and wireless communications in fundamental ways. What does the future of amateur radio look like when radios use machine learning to operate? How does our relationship to the bands change with cognitive radio? Where are we in this transformation? What will happen next?A working group to produce an AI/ML Handbook for Amateur Radio is forming now. Register your interest here: https://forms.gle/4dZsLkmyxCkp8JiF6
Truly Excellent Digital Voice Quality: Opulent Voice
Presentors: Paul Williamson KB5MU
Level: General Audience Category: Digital Voice Mode, DSP and Software Design, Software and Satellites, Space and Satellites Time:
PDT: September 17, 2022, 9:00 am UTC: September 17, 2022, 4:00 pm
Digital voice on amateur radio to date has generally had terrible voice quality, due to both a perception of limited available bandwidth and the convenience (to manufacturers) of repurposing commercial protocols with their older, proprietary, low-bitrate voice codecs. We present and demonstrate a modern digital voice design that can be used on 222 MHz and above with truly excellent voice quality. Source code here: https://github.com/phase4ground/opv-cxx-demod
Haifuraiya – Open Source HEO Satellite Project Proposal
Presentors: Michelle Thompson W5NYV
Level: General Audience Category: Space and Satellites Time:
PDT: September 18, 2022, 9:00 am UTC: September 18, 2022, 4:00 pm
Haifuraiya is an open source highly elliptical orbit amateur satellite project proposal. This presentation will walk through the high-level project proposal. The project features a digital microwave multiplexing transceiver with a failover transponder mode, has an international volunteer team open to community participants, and complies with debris mitigation guidance from the United States Federal Communications Commission. Repository here: https://github.com/phase4ground/documents/blob/master/Papers_Articles_Presentations/Slide_Presentations/haifuraiya/README.md
User Authentication for Amateur Satellites
Presentors: Paul Williamson KB5MU
Level: General Audience Category: DSP and Software Design, Software and Satellites, Space and Satellites Time:
PDT: September 17, 2022, 8:00 am UTC: September 17, 2022, 3:00 pm
After a brief discussion of the reasons why user authentication is needed on an amateur satellite service system, we’ll cover a proposed system to implement reasonably secure user authentication on a P4XT digital multiplexing satellite transponder, within the bounds of the (United States) rules.
We had three project showcases in the Project Gallery
Each Gallery had a Q&A tab, a poster or document, links to any papers, and a link to any associated video presentations.
1) Ribbit, a distributed digital messaging platform
2) Opulent Voice – High Bitrate Digital Voice and Data
3) Open Source Satellite Work is Free of ITAR/EAR
Kumospace Lounge
Thank you to Ham Expo for providing fun and effective Lounges for interaction at the conference. We truly enjoyed visiting with everyone that dropped by! We hope you enjoyed our themed events and the extended Q&A in the Lounges.
-=-=-=-=-=-=-=-=-=-
DEFCON 30 Activity Report
Open Research Institute’s amateur radio open source showcase at the annual hacker convention DEFCON was located in RF Village (RF Hackers Sanctuary) in The Flamingo Hotel. A volunteer crew of seven people from three US states staffed the exhibit that ran from Friday 12 August to Sunday 14 August 2022.
RF Village hosts a very popular wireless Capture the Flag (CTF) event. It is a top tier contest at DEFCON and the winners are recognized at closing ceremonies. RF Village also has a peer-reviewed speaking track. See previous talks in the YouTube playlists here: https://www.youtube.com/c/RFHackersSanctuary
RF Village generously offers space for exhibits from the community. For 2022, the exhibits included Open Research Institute, Kent Britain PCB Antennas, Alexander Zakharov (ALFTEL Systems Ltd.), and Starlink (SpaceX). Starlink brought two stations and allowed visitors to experiment with network and physical security.
Total attendance at DEFCON 30 was estimated at 27,000. Conference events were held in the new Caesar’s Forum + Flamingo, Harrah’s, and Linq convention centers.
Open Research Institute’s exhibit had multiple parts. The entry to the exhibit was a poster session. Posters presented were ITAR/EAR Regulatory Relief for Amateur Satellite Service, Libre Space Foundation’s Manifesto, Authentication and Authorization Protocol for Amateur Satellites, and the Ribbit Project Introduction and Architecture. Ribbit allows an amateur operator to type in SMS messages on an Android app. Each SMS message is converted to digital audio tones. The tones are played out the phone’s speaker into the microphone of an amateur radio handheld or mobile rig. This can turn any analog HT into part of a digital messaging network. The app can do point-to-point communications and also has a repeater mode. More open source implementations are planned.
All posters were enthusiastically well-received. Specific technical feedback was received on the Authorization protocol that will improve the design. There will be a presentation about the Authorization and Authentication protocol at the September 2022 QSO Today Ham Expo.
Visitors understood the purpose and potential of Ribbit and could download the free open source Android app from a QR code on the poster. The code was also on the Ribbit stickers handed out at the booth. All 300 of the Ribbit stickers were handed out by Sunday morning.
Find the Ribbit “Rattlegram” application here: https://play.google.com/store/apps/details?id=com.aicodix.rattlegram
There will be a Ribbit presentation at the September 2022 QSO Today Ham Expo.
The ITAR/EAR Open Source amateur satellite regulatory relief poster garnered a lot of attention. A very large fraction of DEFCON attendees are familiar with ITAR/EAR, which are a set of regulations that govern the way we design communications satellites in the USA. People that read the poster at DEFCON understood and appreciated the value of the work, which provides long-awaited regulatory relief for the amateur satellite service. The poster presentation led to an invitation to Policy Village Sunday afternoon for a panel session hosted by the Office of the National Cyber Director. Summary of that session can be found in ORI’s 19 August 2022 project report. The ITAR/EAR poster will be part of the Projects Exhibits at the September 2022 QSO Today Ham Expo.
Foot traffic flowed past the posters and into the live demonstrations.
The first live demonstration visitors encountered was from OpenRTX (https://openrtx.org). This demonstration used a tablet computer running OpenWebRX to display modified MD-380 transmissions. Visitors could use headphones to hear live transmitted signals. Posters at the table explained the modifications required to implement the M17 protocol on the MD-380 and described the motivation and value of the work, with an emphasis on the use of the free and open CODEC2 voice codec. The use of CODEC2 in M17 replaces the proprietary AMBE codec found in every other digital voice protocol for VHF/UHF ham radio. There was strong interest in both the M17 and the DMR work from OpenRTX, broad understanding of why proprietary codecs are not ideal, and consistently positive feedback. 500 OpenRTX business cards were printed with QR codes for the OpenRTX website and nearly all of them were handed out.
The second demonstration was Opulent Voice. This is a high bitrate open source voice and data protocol. It’s designed as the uplink protocol for ORI’s amateur satellite program. The Authentication and Authorization fields are built in and sending data does not require a separate packet mode. The baseline voice codec for Opulent Voice is OPUS at 16 kbps. Higher bitrates are a build-time option. For the DEFCON demonstration, Opulent Voice was transmitted from an Analog Devices PLUTO SDR and received on an RTL-SDR/Raspberry Pi. Visitors could use headphones to listen to the received audio. The modulator and demodulator code can be found at https://github.com/phase4ground/opv-cxx-demod. 300 custom art stickers for Opulent Voice were ordered and all were handed out.
The two demonstrations compared and contrasted voice quality (3.2 kbps vs 16+ kbps), regulatory limitations (VHF/UHF vs. microwave), and approach to framing (P25 style vs. COBS/UDP/RTP).
The next station had stickers, buttons, patches, ORI’s Tiny CTF, Haifuraiya proposal printouts, and a Trans-Ionospheric badge display.
ORI’s “Tiny CTF” was a hidden web server, accessible from the wifi access point located at the OpenRTX demonstration. The access point allowed people to view the OpenWebRX display directly on their connected devices. Participants that found the hidden web server and then blinked the LEDs on a certain piece of equipment at the booth received a prize.
Haifuraiya (High Flyer) is an open source highly elliptical orbit communications satellite proposal. Microwave amateur band digital communications at 5, 10, and 24 GHz are proposed. Transmissions are frequency division multiple access Opulent Voice up, and DVB-S2/X time division multiplexed down. A presentation about this proposal will be at the September 2022 QSO Today Ham Expo.
Based on the feedback about the amateur radio themed Trans-Ionospheric badge, ORI will update and build another round of these badges. Round one of the Trans-Ionospheric badge was a very successful open source project fundraiser. The badges have been enduringly popular in the community, and they can serve as radio peripherals that display radio link and payload health over bluetooth. The artistic design of the badge is based on the front panel of the Zenith Trans-Oceanic radio. Find out more about the Trans-Ionospheric badge here: https://www.openresearch.institute/badge/
There were very high levels of interest, enthusiasm, and positive feedback throughout the weekend. Friends from Ham Radio Village and Aerospace Village visited the exhibit and shared their experiences. The organizational support from RF Village leads was excellent. ORI will return to DEFCON in 2023 with another round of open source digital radio demonstrations.
Amateur radio experimenters and their projects are welcome at Open Research Institute. Individuals can join for free at https://www.openresearch.institute/getting-started/. Projects can apply at https://www.openresearch.institute/your-project-is-welcome/
Opulent Voice – digital voice and data protocol update
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 transponder project. Opulent Voice is also looking pretty darn good for terrestrial.
Here is an audible example of the Opulent Voice audio quality under ideal conditions. Each file is about 37 seconds long. It starts with a short musical intro, and the rest is the beginning of the audio track from one of Michelle’s conference talks. These were originally recorded with mid-range podcasting studio gear. The recording was converted to a signed 16-bit PCM raw file, which has been re-converted to a standard WAV file so you can play it easily, MDT-short.wav
This file was then run through opv-mod to create a file of baseband samples, which was then piped to opv-demod, which created an output file of signed 16-bit PCM. That file was converted to WAV file MDT-short.demod.wav
We expect to present a nice demo at DEFCON in August 2022 and at the QSO Today Ham Expo in September 2022.
We’ll be using COBS protocol within Opulent Voice. If you’re unfamiliar with COBS, please read about it here:
https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing
Authentication and authorization is built in and optional. There is no separate “packet mode”. Things are designed to “just work” and get out of your way whether or not you’re sending voice or data.
Opulent Voice is designed to where you can use even higher bitrate OPUS codecs if you wish. This will most likely be a build option and not a run-time option, but if a run-time option is something you want to work on, speak up! Let’s see what we can accomplish.
Originally based on Mobilinkd codebase that implements M17, the Opulent Voice development implementation can be found here:
https://github.com/phase4ground/opv-cxx-demod
Initial demos will be on a HackRF/PortaPack on the 1.2 GHz ham bands.
Thank you to OpenRTX for help with troubleshooting the audio quality on the PortaPack. In order to have a good demo, basic FM transmit from the microphone needs to work. The audio quality is pretty bad (this was a surprise) with the stock application, so we’ve been spending some time with the Mayhem codebase, the microphone transmit app, and the driver for the audio codec in order to get it sounding like it should. This needs to happen before we publish an app for the PortaPack.
Synthesized audio from the HackRF/PortaPack sounds clear and wonderful. It’s just the microphone that is splattery and overdriven.
ORI’s Slack channel can be found at https://phase4ground.slack.com/
The authentication and authorization work is in #aaaaa
Opulent Voice work is in #opulent-voice
Thank you to everyone supporting the work!
-Michelle Thompson
Video of Working Meeting on Higher Bitrate M17
Specification of M17:
P4DX architecture document:
https://github.com/phase4ground/docum…
M17 is P4DX native digital uplink protocol.
There are at least three use cases of M17.
One, 9600 bps voice for VHF/UHF.
Two, the idea of 9600 bps data or packet mode, also VHF/UHF.
Three, higher bitrate mode for microwave.
There is a data type specifier in the current specification. Reserved protocol types are RAW, AX.25, APRS, 6LoWPAN, IPv4, SMS, and Winlink.
What we’re talking about today is what, if anything, needs to be added to the specification in order to enable high bitrate operation for microwave, and also to figure out if anything needs to be done for IP over M17 or M17 over IP.
From Slack:
Ron
What needs to be defined is how to do IP over M17. In the M17 specification, there’s a protocol identifier for IPv4, but that’s it.
And here is a review of the conversation from 2021. This was the starting point for the conversation in this video recording.
Ron
M17 supports IPv4, but I’m not exactly sure how. The M17 specification seems pretty vague on that particular point
Howie
Assume we consider M17 stream mode operating in an FDM manner with a receiver for each uplink channel. Each channel can be given a GSE label that could map to an uplink center freq. The 4FSK modulated data is demodulated but not decoded. Instead, the data streams are clocked into individual buffers and used to generate the GRE frames. The idea is to keep the M17 frames intact so that on the ground earth station the demodulated data is identical to the uplinked frame which can be processed by the existing M17 decoder software. You listen to a channel by selecting the label for the stream you want to listen to. The limiting factor becomes how fast you can assemble the uplink channels into GRE frames.
I don’t think there is any need or desire to use anything other than native M17 on the uplink. While GSE is normally used for IP transport I think we could put the M17 frames into the GSE data field. At that point the only overhead is on the downlink with the addition of the GSE headers and LSF management. I have not looked closely at the sizes of the required fields are or how much processing it would take to multiplex multiple uplink streams into a composite downlink. At this point I am just brainstorming.
Anshul
looks like we don’t need IP as an intermediate step. I agree with @ab2s that there is no need to use anything other than native M17 on the uplink. GSE should encapsulate M17 frames and produce BBFRAME as it normally does for IP packet.
It implies we will be not using any IP stream/packets on uplink. Everything uplink will be M17 based.
Do you see any concerns here . Else, I will proceed with implementation of GSE block in firmware keeping this decision in mind.
Consensus on:
- Validity of use case for higher bitrate M17 for P4DX uplink.
- IP over M17 could use an example (as could all the types in this field), but the type field indicating IPv4 is sufficient for carrying IPv4 within M17. M17 packet is small enough to where IP fragmentation will probably occur.
- M17 over IP is defined in the appendix, it works as implemented in the reflector network, and did not appear to need any additional work.
- P4DX could provide a spigot of M17 uplinks over IP, using the protocol in the appendix, as a Groundsat feature. This would not affect the air interface.
- We discussed the XOR with random data aspect (covert SPARROW channel here? Yes/maybe if there’s a known message)
- Discussed asking for a P4 Type Field Indicator. Smart receivers won’t need this, but it would allow people to move between 9600 bps M17 and higher bitrate M17.
HamCation 2022 Report
HamCation 2022 Report
Paul Williamson (Remote Labs), Douglas Quagliana (P4DX), Michelle Thompson (ORI), Ed Wilson (M17), and Steve Miller (M17) represented the breadth of projects from Open Research Institute at HamCation 2022.
ORI’s “Tonight’s The Night: SDRs are HOT” booth made its first appearance in nearly two years. Available at the booth were stickers, pins, patches, shirts, consulting, and project updates. ORI’s “extra chair” seating area was appreciated by volunteers and visitors alike. Booth visitors heard about the successful DVB-S2X modem work from ORI and progress on the end-to-end demo of the entire satellite transponder chain. At Open Research Institute, it doesn’t work until it works over the air. Due to the efforts of a truly wonderful international open source team, the custom FPGA code is coming together very well, and Remote Labs continues to evolve. The Phase 4 Digital Multiplexing Transceiver project is on budget, on track, and highly likely to succeed. The return on investment is high. The team isn’t anywhere near done innovating, publishing, and enabling high-tech space aand terrestrial amateur radio work. If you want to be a part of this, or just follow along, visit https://openresearch.institute, go to “Getting Started”, and sign up for the Phase 4 Ground mailing list. This is “home base” for announcements from ORI.
Right beside ORI’s booth was the “future of amateur radio”, the M17 Project. Ed and Steve from M17 brought working hardware, firmware updates, and also demonstrated several different software implementations throughout the weekend. M17 held their weekly net on Friday live from the booth, gave away stickers, magnets, and pins, and captured the hearts of all who visited. You can get involved with this project at https://m17project.org
AmbaSat re-spin was a frequent topic of conversation. The five AmbaSat boards from ORI, which operate at 70cm, have been distributed to the firmware team, and they have begun development and are seeing success in university and hobbyist labs. The goal is to create a compelling application, put the hardware on a sounding rocket, apply for a launch license, and send this project to space in a way that makes the amateur community proud. While “AmbaSat Inspired Sensors” is ORI’s smallest received grant, it has by far the highest capability return on investment of any ORI project.
ORI and M17 booths were located in the North Hall. While the other buildings are larger and many consider them to be higher profile, booths in the North building are what you must walk by to get to the Information Booth and Prize Booth. Since the vast majority of participants visit this part of the show, it is, in our humble opinion, the best possible location.
Michelle Thompson (W5NYV) presented about Digital Communications Technology at the ARRL Expo Technology Track held on Thursday at a conference center near Seaworld. There were four tracks of presentations at the Expo: Contesting, Handbook, Technology, and Emergency Communications.
Michelle reported a positive, enthusiastic, and engaged audience for her ARRL Technology Track talk, and has high hopes that ARRL will continue doing events like this moving forward. She discussed ORI’s Polar Code initiative, successful regulatory and legal work, why open source LDPC work is so important to amateur radio, the four fundamental components to digital communications, and why the M17 protocol was selected as ORI’s satellite uplink protocol for the P4DX transponder project. Michelle invited M17 principals to speak about their work, and opened the floor for questions and comments from the many highly competent and curious technical hams that were in attendance. Subjects covered ranged from asynchronous computing to concatenated coding. The rumors about toilet paper being a fundamentally important part of this presentation are entirely true.
ORI organized a Friday forum track for Clearspan Tent #1 that ran from 11:15am until closing. HamCation was extremely generous in giving us time to present work from a wide variety of people. Here’s our lineup for 2022.
11:15 am
Understanding and Changing Amateur Radio Regulation / Open Source Digital HTs are Real! by Bruce Perens (K6BP)
12:30 pm TAPR – TangerineSDR Update, or How to build an SDR without any parts by
Scotty Cowling (WA2DFI)
1:45 pm M17 Project by Ed Wilson, Steve Miller (N2XDD, KC1AWV)
3:00 pm GNU Radio work at ORI / FreeDV HF Voice Update 2022 by Douglas Quagliana, Mel Whitten (KA2UPW, K0PFX)
3:00 pm Society of Amateur Radio Astronomy SARA by Tom Crowley (KT4XN)
At both the Expo and HamCation, ARRL set the pace this year for satellite talks and satellite demonstrations, with a video (please see https://www.youtube.com/watch?v=fhyUbC_o1JM&ab_channel=ARRLHQ) providing practical examples of amateur satellite operations. Patrick Stoddard (WD9EWK) gave a tutorial on satellite operations at the ARRL Expo in the Handbook Track. Amateur satellite was very well supported from ARRL this year, and we have heard this will continue to strengthen going forward.
With some optimism, ORI looks forward to returning to in-person events. The next planned in-person event is DEFCON (https://defcon.org/). Last year, DEFCON was held in person. Proof of vaccination was required. Masks were required. It was a highly successful and enjoyable event. This year, for 2022, ORI will be represented in DEFCON villages and activities. We are looking at applying for M17 to be part of Demo Labs, multiple radio links between villages to demonstrate a wide variety of technology, and presentations about the R&D that we do.
If you would like to be a part of this, and we do need you, then please join the Slack channel for DEFCON planning. Quite a bit of work is underway already. The goal for DEFCON 2022 is over the air demonstrations, outreach, fun, swag, and supporting our friends at all the villages we’ve been involved with over the years.
DEFCON is run very differently from traditional amateur radio conventions. The most significant practical difference is that DEFCON has a written code of conduct, and those written community standards and policies are enforced. It has a very diverse and very interdisciplinary attendance. Unlike many technical or hobby conferences, participation in the DEFCON community is possible year-round through participation in local groups that meet monthly.
DEFCON is a very large event, with attendance of over 30,000.
DEFCON is devoted to a very broad spectrum of experimental, commercial, and open source work. Participation by the government, industrial, information security, hacker, hobbyist, and scientific communities has steadily grown over the past 30 years.
The next virtual event for Open Research Institute is Ham Expo, 12-13 March 2022. Andre Suoto will have an excellent talk about our open source LDPC encoder for FPGAs and ASICs. This is in the main track. We will have a wide variety of work and projects represented at our booth, which is in the vendor hall. Open Research Institute is a non-profit sponsor of Ham Expo. We’ll have friendly and accessible “office hours” during the event.
Quarterly Technical Advisory Committee Meeting 5 February 2022
HamCation 2022
This post will be updated with information leading up to and throughout the event. Thank you to HamCation for the support and opportunity.
Tucson Amateur Packet Radio
Booth, prototypes, forum presentation, give-aways, and more!
Society of Amateur Radio Astronomers
Forum presentation.
M17 Project
Booth, forum presentations, give-aways, and more!
Open Research Institute
Booth, demonstration reports, give-aways, sales, and more!
ARRL Technology Track
Talk by Michelle Thompson W5NYV.
Abstract:
Digital communications technology is large interdisciplinary field that incorporates some of the most fundamental scientific advancements of the past 120 years.
From the first spark gap transmitters, to telegraph, to the transistor, to the fast fourier transform, to the tape drive, to telnet, to touchscreens and trace routes, trackballs and telecommunications of all sorts, digital transmission of everyday information has revolutionized the way we communicate with each other, the way we store data, and the way we process that data to create things of greater and greater value.
This talk is about how information travels over the air in ways relevant to motivated amateur radio enthusiasts.
Digital communications is a difficult subject. This talk is simplified, but definitely not dumbed down. You will leave this session with a greater intuitive understanding of how digital communications works.
There’s a vibrant community and growing body of work in open source amateur radio digital communications for space and terrestrial work. The talk will close with a brief summary of open source digital communications work at Open Research Institute, Inc., a 501(c)(3) dedicated to open source work for amateur radio and beyond.
Demonstration: FreeRTOS Task Upload
This is a Scheduler for Dynamic Patching of FreeRTOS Tasks. It’s based on FreeRTOS and it helps the user to dynamically update and patch the task without the need for system reboot.
Weekly Engineering Report 10 August 2021
Greetings all!
1) OpenRotor will have a Ham Expo workshop from 12:00pm – 2:00pm in the Chat. Direct link is: https://ori.whereby.com/open-research-institute
Get there by clicking “Chat” in the booth at Ham Expo.
2) Planning spreadsheet for ORI at Ham Expo has been started and the editable version is linked in the Slack.
Please add yourself if you have something to present on any open source amateur radio or amateur radio satellite service subject. Coordinate through Slack. We have excellent resources and support from Ham Expo this year. The goal is to provide a low-stress enjoyable venue to speak with attendees about the things we do and the things we want to see succeed.
I need videos of demos or time commitments for live demos. Don’t be shy – your work is of great interest at the Expo.
3) If you are not on our Slack, or haven’t visited lately, please do – this is where daily engineering and planning happens.
https://phase4ground.slack.com/
If you need an invite, please send me a request directly.
4) FPGA Standup meeting was today and the team will have a lot to show off at Ham Expo and for Google Skywater in October. Most recent recording of the weekly standup is:
5) DEFCON was a big success. We had our first in-person board meeting in nearly two years. A lot of networking and discussion and learning happened. There are several projects that we might want to consider supporting or assisting. More about those projects in the #defcon channel in Slack.
6) ORI Store (https://stores.goldmedalideas.com/ori/shop/home) will have a promotion. We have a supply of the 2019 printed paper versions of the AMSAT Getting Started With Amateur Satellites Guide and will include one in every order over $30 starting at Ham Expo and lasting until supplies are gone.
7) Open Lunar Foundation lab purchase is complete and the lease for storage of that equipment is being transferred from Open Lunar to ORI this week. The lab equipment will move to primarily M17 Lab on the East Coast and some will go to Remote Lab South in Arkansas this autumn. If you can help reduce shipping costs then get in touch.
8) FCC has agreed to meet with us and will arrange for both OET and the International Satellite Bureau to attend. The agenda is how open source can successfully address Debris Mitigation regulatory requirements for the amateur radio satellite service, and specific microwave band spectrum defense for the amateur radio satellite service. A summary of the content for this meeting will be presented at Ham Expo. There will be a breakout session and Q&A.
9) Work session at Huntsville Space and Rocket Center for the Birdbath Big Dish renovation has been postponed due to covid. Originally scheduled for immediately following Huntsville Hamfest, the work session will happen when it’s safe to invite volunteers to work together on site. This project renovates a 20 foot dish for open source amateur and citizen space science use.
-Michelle W5NYV
OpenRTX Firmware Measured in Remote Lab West
Ground-based DVB-S2 Repeater for GEO Satellites by Wally Ritchie.
In case you missed it when it was published by AMSAT-UK, you can download the paper here.
Dual-Band Feeds Update
My background is baseband and algorithm development, but the RF side is where the signals meet and exceed the sky. I have only the deepest respect for those that are talented here and give generously of their time for amateur satellite project success. We owe so much to Kent Britain, Paul Wade, and many others.
There are two designs for Phase 4 dual band feeds in the repository linked here. They are dual-band feeds, best used in dishes.
https://github.com/phase4ground/documents/tree/master/Engineering/Antennas_and_Feeds
The first one I want to introduce you to is the 5 GHz up, 10 GHz down. This feed was designed by Paul Wade W1GHZ, has lab results, has been manufactured in amateur machine shops, and has been 3d printed/metallized. This feed was demonstrated at amateur and IEEE conferences.
The second is 10 GHz up, 24 GHz down. Paul fabricated a number of feeds for us to distribute. The design is by Gary K6MG and Lars AD6IW. Their paper can be found at https://dokumen.tips/documents/dual-band-1024-ghz-feedhorns-for-shallow-ad6fp-aa6iw-dualfinalpdfdual-band-1024.html?page=1.
Preliminary lab results are in progress and published in the repository. More to come! ORI bought 15 of them and is interested in putting them into the hands of amateurs that will use them and report back. Three have been sent out so far, and we are looking to send out more.
While the baseline Phase 4 design is “five and dime”, the goal of ORI is to use any and all microwave bands that we can. I think we are all aware of how much pressure our microwave bands are under from commercial interests.
The system design is extensible to 10/24, so we needed a feed for this.
If you want to contribute or participate, then please visit
https://www.openresearch.institute/getting-started/
Thank you to all that have helped make this possible!
-Michelle W5NYV
26 March 2021 Engineering Report
Here is a visual walkthrough of the features on the TEBF0808 UltraITX+ Baseboard for Trenz Electronic TE080X UltraSOM+, presented by Paul KB5MU and Michelle W5NYV.
These stations are available to the community from Open Research Institute’s Remote Labs. We currently have two sets of gear and are procuring two more.
The Trenz platform allows for full access to the FPGA, power reduction work, and thermal modeling. All are extremely important for space applications.
We also have the Xilinx development board for the Ultrascale, for preliminary work.
The FPGA module goes in the lower left empty square with the high-density connectors.
The FPGA module has a heat sink, called a heatspreader, that is a machined metal plate. It attaches to the FPGA module with screws. However, it needs an intermediate layer to conduct the heat from the FPGA to the metal plate. The plate is designed to fit many different modules, and there’s a gap between the metal plate and the top of the components on the FPGA module.
This gap is usually filled with a specific gap-filling thermal paste.
Which happens to be out of stock, all over the world.
So, of the four stations we’re settting up, one will be fitted with a thermal adhesive film. This comes in sheets and can be cut to size. It can be used for space, so as we dial down the power consumption with code adjustments, we can measure the thermal results with something that is appropriate for the space mission.
The other three will get gap-filling goo directly from Trenz. This is the only way to preserve the warranty on these expensive modules, so it’s not a bad choice. And, this gives us something to compare the sheet against. We’ll test both in thermal modeling and chamber.
-Michelle W5NYV
Excess Equipment For Sale
We have excess lab equipment that is now for sale!
— OpenResearchInstitute (@OpenResearchIns) January 27, 2021
All proceeds go directly back to the Phase 4 project. Learn more about that at https://t.co/ReSTT6mOfT
Analog Devices ADRV9371-W/PCBZ evaluation board listing is here:https://t.co/rI2Et3pnqv
Remote Labs Report for January 2021
Engineering Report 11 December 2020
Content:
## Phase 4 Weekly Report for 11 December 2020
#### Architecture 9 December 2020
Progress this week on detailed architecture for the exciter. The short term goal is to be able to write base-band frames (BBFRAMES) to the buffer and send them out. BBFRAMES are connected to ethernet on the A53 side. This will achieve our original Phase I goals. Wally Ritchie leading efforts on the modulator and the interfaces so we can integrate the existing FEC code.
#### Remote Labs 9 December 2020
Video report from Remote Lab West available here: https://youtu.be/z0d1vvbX_LU
Video shows unpacking and deployment of the logic analyzer accessory for the mixed-signal oscilloscope. Device under test is an RC2014 and the signal inspected was RS232. Some concern here because we can get single characters and short bursts perfectly, but longer bursts of RS232 are not successfully decoded. Nick and others have given advice and it will be followed up on.
Signal generator for Remote Lab West expected Friday 11 December 2020. Remote Lab East has their signal generator with the upgraded clock already.
Trenz gear delayed, date TBD.
#### 9 December 2020 Meeting Notes – Open Lunar Foundation Use of ORI Radio Designs
Participated in a working meeting on how to use ORI’s transponder work in the NASA grant ecosystem. Answered questions, shared documents, and took some action items from Open Lunar Foundation.
#### 8 December 2020 Meeting Notes – Open Lunar Foundation Donor Summit
Attended a donor summit held by Open Lunar Foundation. Answered questions about ORI, P4XT, open source licensing, and how best to use the ORI transponder and ground equipment as a base design for Open Lunar Foundation’s efforts to provide solutions for LunaNet and beyond.
Learn more about Open Lunar Foundation at:
#### 8 December 2020 Meeting Notes – Debris Mitigation, GMAT, and Orbits
Wally Ritchie
Anshul Makkar
Michelle Thompson
**AI:** = Action Items
GMAT stands for General Mission Analysis Tool. This is an open source framework from NASA that allows high-fidelity mission planning. Find more information about this tool here:
https://opensource.gsfc.nasa.gov/projects/GMAT/index.php
Our LEO-to-GEO GMAT models by Achim Vollhardt can be found here:
The LEO-to-GEO GMAT models shows what we need to do to get to GEO on our own. They allow us to do a trade study between motoring to GEO from LEO vs. paying for a launch to GEO. In both cases, we need to model the GEO-to-disposal orbit, which is one of the things Anshul Makkar is working on.
There are multiple variables to consider when comparing LEO-to-GEO against straight-to-GEO, including:
1) debris mitigation concerns because spiraling up through what may be very large LEO constellation may raise objections, where straight-to-GEO does not, at increased launch expense.
2) the capability cost to LEO-to-GEO due to the larger amount of space required for fuel.
3) increased radiation exposure of a LEO-to-GEO spiral, which drives up cost and potentially capability.
Anshul is creating a GMAT mission to model desired orbits for P4XT. He had some questions about Debris Mitigation, GMAT, and the impact on orbits. Here is a summary of the discussion and the resulting action items and goals.
Anshul has been working through some examples to learn GMAT and has had success. He came to the point where he needed to know more about the parameters.
For Anshul’s initial round of work, we will model from GEO delivery to disposal orbit.
We currently refer to this as “Straight to Graveyard”.
The disposal orbits are 250 km above and below GEO.
The upper stage of the launches we expect to be able to take advantage of deliver payloads 50 km above or below GEO. The final maneuvering is typically done by the primary payload after separation from the final stage. This orbit, 50 km out, is called the “maneuvering zone”.
While we would like an equatorial disposal orbit, we can handle inclinations.
Wally shared some paper about some stable orbits available in disposal.
**AI:** Wally to send Anshul an edition of a good book resource on orbital mechanics.
With this GMAT mission creation, we will have three line elements (TLEs) that will enable ground station tracking modeling in currently available software.
**AI:** GMAT animations will be created to show a train of 4 payloads for global coverage.
The advantages to Straight to Graveyard are significant.
1) With a GEO-to-dispoal, we do not have to have the estimated 2 lbs of Iodine thruster fuel for a LEO to GEO orbit, modeled previously by Achim.
2) We do not suffer the wear and tear a LEO to GEO mission incurs.
3) We can use the saved space for more and better batteries, which increases mission life.
Given the reduced stationkeeping requirements of disposal orbits, we may be able to use open source thruster technology such as AIS work to maintain attitude.
The disposal orbit does require some tracking. However, it is slow. It also provides additional DX opportunities for operators. Path loss will vary more. Anything below 20 to 15 degrees elevation is challenging.
**AI:** Anshul to use existing GEO orbits and modify this mission with a burn to disposal to achieve the simplest Straight to Graveyard mission presentation.
**AI:** Anshul to present his work.
debris_mitigation Slack channel created for discussion, and relevant foundational documents have been shared there.
#### Virginia Tech Industrial Advisory Board Meeting Report
Open Research Institute attended our first Virginia Tech Industrial Advisory Board Meeting on 20 November 2020. The meeting was attended by over 40 representatives from industrial, academic, amateur, and open source communities. The goal of the Industrial Advisory Board is to improve Virginia Tech’s ability to educate students for roles in space exploration, science, technology, regulation, and management.
**Action items:** prepare 2-3 slides about ORI and our mission on the Industrial Advisory Board. Open source regulatory advancements, positive effect on commerce when used appropriately, and the improvement in educational outcomes are the communications goals for the slide deck.
#### High-Level Discussion on Thermal and Radiation
Action Item closed: Thermal Desktop license successfully installed on a FlexLM server donated to the cause by the power of KN6NK.
Current status: having trouble getting the license from the server to the local installation.
**New Action Item:** Tutorials completed using this software.
Mike Murphree requested a mission plan and expectations on the radiation environment as soon as possible.
Mike Murpree requested resource utilization of the Xilinx parts in order to compare against other potentially more radiation tolerant families of parts.
Michelle to provide documentation on the block diagrams and architecture documentation.
#### Trello Boards up and running
We are using Trello for task management. Plenty going on!
Join Phase 4 Ground Trello board:
https://trello.com/invite/b/REasyYiZ/8de4c059e252c7c435a1dafa25f655a8/phase-4-ground
Join Phase 4 Space Trello board:
https://trello.com/invite/b/GRBWasqW/1336a1fa5b88b380c27ccf95d21fec79/phase-4-space
#### AmbaSat Inspired Sensors
Account at Wells Fargo set up and dedicated funds from ARDC deposited.
#### Ham Expo 2021 Participation
ORI will present at and be part of an exhibit at the Ham Expo 2021. Details about the event here: https://www.qsotodayhamexpo.com/
**We will be using this event as a deadline for transponder work.** We will demonstrate functionality complete by March 2021 at the show.
#### HamCation 2021 Participation
We will participate in HamCation 2021. This is a virtual event. We have 45 minutes available for presentations. HamCation wants unique, fun, engaging, interactive events. This is a wonderful opportunity for us. Message from organizers after we committed: “We don’t have a schedule yet. Plan on 45 minutes for the webinar with a 15 minute break between. Please provide a topic for the presentation with short description that will be posted. Thank you for offering.”
Topics for presentation and short descriptions need to be drawn up. We could do a competition, quiz bowl, live demo, technical presentation, contest, or anything of the sort.
#### Regulatory Presentation
The report is called “Minimum Viable Product” and the Debris Mitigation activities fold into this presentation. Version 1.2 received from Jan King on 7 December 2020.
Engineering Report 20 November 2020
## Phase 4 Weekly Report for 20 November 2020
#### Virginia Tech Industrial Advisory Board Meeting Report
Open Research Institute attended our first Virginia Tech Industrial Advisory Board Meeting on 20 November 2020. The meeting was attended by over 40 representatives from industrial, academic, amateur, and open source communities. The goal of the Industrial Advisory Board is to improve Virginia Tech’s ability to educate students for roles in space exploration, science, technology, regulation, and management.
The first part of the meeting was a description and orientation of the re-dedication of the Industrial Advisory Board lead by Scott Bailey. The second part of the meeting was a curriculum review lead by Dr. Jonathan Black. The next meeting will be in the Spring.
**Action items:** prepare 2-3 slides about ORI and our mission on the Industrial Advisory Board. Open source regulatory advancements, positive effect on commerce when used appropriately, and the improvement in educational outcomes are the communications goals for the slide deck.
#### High-Level Discussion on Thermal and Radiation
We had a high-level discussion about thermal and radiation requirements and work on 19 November 2020. The goals of the meeting were to introduce volunteers with experience in these areas to each other, and to generate any action items necessary to clear roadblocks for future work. Initial list of action items:
**Meeting Minutes**
Attending were Michelle Thompson, Mike Murphree, Thomas Savarino, Alan Rich, and Nick KN6NK.
We use FlexLM for our Vivado license server, generously donated by KN6NK, and we will be able to use this server for Thermal Desktop. This is limited to one user, Thomas Savarino, but we are satisfied with this work plan. Thomas will also need Parallels and Autodesk. Invoices requested.
Alan Rich provided valuable advice about thermal engineering. Junction temperature and thermal cycling are of primary interest. We need to expect to do a layer analysis and treat the board like a structure. Concerns for radiation were discussed which align with previous work by Wally Ritchie, Thomas Parry, and Suoto.
Mike Murphree requested a mission plan and expectations on the radiation environment as soon as possible.
Mike Murpree requested resource utilization of the Xilinx parts in order to compare against other potentially more radiation tolerant families of parts.
Michelle to provide documentation on the block diagrams and architecture documentation.
*Priorities? Get the Thermal Desktop software up and running so Thomas Savarino can train on it and then start characterizing the 1U circuit cards for the communications payload.*
###### Open Research Institute sponsors the M17 Project
Open Research Institute is proud to sponsor M17, an open source digital radio protocol, code, voice codec, and hardware project.
Learn about and get involved at
https://m17project.org/
M17 has been added to the list of Open Research Institute Projects at
#### Trello Boards up and running
We are using Trello for task management. Plenty going on!
Join Phase 4 Ground Trello board:
https://trello.com/invite/b/REasyYiZ/8de4c059e252c7c435a1dafa25f655a8/phase-4-ground
Join Phase 4 Space Trello board:
https://trello.com/invite/b/GRBWasqW/1336a1fa5b88b380c27ccf95d21fec79/phase-4-space
#### AmbaSat Inspired Sensors
Phone conference with Dr. Alan Johnston on 2 November 2020 to answer questions and set up a tentative schedule. Work is expected to commence December 2020 through May 2021. This work is funded by an ORI grant. Project kickoff report here: https://www.openresearch.institute/2020/11/12/ambasat-inspired-sensors-project-kick-off-in-december-2020/
#### Remote Labs
Equipment has begun to arrive for the Remote Labs project. Access protocols have been drafted and tested. Feedback has been received and incorporated. Report and link to overview video here: https://www.openresearch.institute/2020/10/24/remote-labs-equipment-review/
Tracking document will be moved to the GitHub Wiki, but the current draft is here: https://docs.google.com/document/d/1EG_anaUNWxluriktrDBUa1MnIdIlOe9_hMCkNFj3Tc4/edit?usp=sharing
#### Ham Expo 2021 Participation
ORI will present at and be part of an exhibit at the Ham Expo 2021. Details about the event here: https://www.qsotodayhamexpo.com/
**We will be using this event as a deadline for transponder work.** We will demonstrate functionality complete by March 2021 at the show.
#### HamCation 2021 Participation
We will participate in HamCation 2021. This is a virtual event. We have 45 minutes available for presentations. HamCation wants unique, fun, engaging, interactive events. This is a wonderful opportunity for us. Message from organizers after we committed: “We don’t have a schedule yet. Plan on 45 minutes for the webinar with a 15 minute break between. Please provide a topic for the presentation with short description that will be posted. Thank you for offering.”
Topics for presentation and short descriptions need to be drawn up. We could do a competition, quiz bowl, live demo, technical presentation, contest, or anything of the sort.
#### Regulatory Presentation
We will present to the FCC, accompanied by ARRL counsel, in the next small number of months. This presentation will emphasize how open source technologies and policies strengthen the Amateur Radio Satellite Service. The presentation will show how the Amateur Radio Satellite Service can fully comply with Debris Mitigation, how it can and will continue a rich history of providing quality public service communications, and how it will be a full participant in the New Space Age.
#### Ed Friesma Needs Help
One of our volunteers, Ed Friesma, writes
“We’re submitting a proposal here at UNLV to get a Cubesat off the ground and I’m in charge of the communications team (both hardware and software) We are submitting our base proposal for review but I will have to get a team of students together. A mentor would really help here. Especially when it comes to building the ground station. but also testing the comms link and the ground station software.
Do you know anyone
a) with some good experience setting up communications with Satellites and also boradcasting to satellites over UHF.
b) who would be interested in occasionally speaking with and answering questions from our team.
They don’t necessarily have to be in the area but at least be open to using Zoom or Discord to chat with us.”
Ed has the right experience to put this team together, but would like to run things by someone that’s been there before. It would really help to sort out what must happen over the next few months.
Are you willing and able to mentor Ed’s team? Get in touch with me at w5nyv@arrl.net and I’ll get you in touch with Ed if you don’t already have his email.
Remote Labs Equipment Review
Transcript of Introductory Remarks
Greetings all,
Welcome to the Open Research Institute Remote Labs Equipment Review.
Open Research Institute (ORI) is a non-profit research and development organization which provides all of its work to the general public under the principles of Open Source and Open Access to Research.
Remote Labs are two physical lab benches. They have equipment for advanced digital communications design work. This equipment will be accessible online to anyone, anywhere that wants to work on open source amateur radio satellite service or open source amateur radio terrestrial engineering development.
The primary focus of the equipment list reviewed today is to support the design, verification, and test of the DVB family of links. DVB-S2, S2X, and T2 are all commonly found in amateur radio. DVB-S2X is the protocol family used by Phase 4 Ground and Space.
Remote Labs is a part of an extremely important process of re-establishing free and open international collaboration with groups such as AMSAT-DL, JAMSAT, and AMSAT-UK, and to increase and amplify collaboration with Libre Space and other open source groups. This is possible for ORI to do by using the open source carve-outs in the US export control regulatory framework. These controls have impeded international cooperation on amateur satellite work for a long time.
A significant amount of regulatory relief was achieved over the summer by ORI for amateur radio satellite work, and more work is going on right now to build upon this success. Please see the Open Research Website news section for more details on that. Today’s discussion is not about satellite technology, but about the equipment and resources required.
We are fortunate to have the advice and input of people that make a living by using remote labs at work. The advice received so far has been heard and acted upon. Python, HTML5 plus Javascript, and command line access will be the initial methods upon to provide secure access to the equipment.
We will not be writing or using a heavy or complex software framework for the Remote Lab. We will be authorizing and authenticating users. It is highly likely that we will use the same authentication and authorization approach that we intend to use for payload communications access, in order to get more experience with that design. In other words, you may be authenticated and authorized for Remote Labs the same way that you will be authenticated and authorized for the payload communications system.
We will definitely be documenting how to use the lab. We will be responsive to feedback about accessibility and ease of use.
There will be someone physically present at the Remote Labs. The equipment is not installed in racks at an unattended site. If a function needs on-site setup, or a test plan can only be done with someone physically at the bench, then that’s how the work will be done.
Remote Labs is offered as a community resource. Therefore, the review process must include community feedback. Thank you for your time here today to discuss and review the equipment list.
As an example, Thomas Parry has provided the following feedback.
1) The initial list had no power supply listed.
2) A computer controlled coax switch matrix would be very useful to control where the signals are going between test gear, DUT, etc. without physical intervention
3) Some form of general purpose digital/low frequency IO device like an analog discovery would be pretty useful for controlling things remotely
4) A way to get arbitrary RF in and out of the PC, ie. an SDR, would be very useful
5) And please remember cabling.
Wally Ritchie responded with an updated list that includes coax relays controlled from a USB relay board(s), and the other items.
Our practice will be validate and measure any cables we make in-house, buy, or obtain as surplus or donations.
I can answer your questions about budget, operation, and policy at the close of the review, or via email.
Please welcome Wally Ritchie who will lead todays Remote Labs Equipment Review.
CJ Determination: Open Source Satellite Work is Free of ITAR
CJ Determination: Open Source Satellite Work is Free of ITAR
The United States Department of State has ruled favorably on Open Research Institute’s commodity jurisdiction request, finding that specified “Information and Software for a Digital Microwave Broadband Communications System for Space and Terrestrial Amateur Radio Use” is definitely not subject to State Department jurisdiction under ITAR, the International Traffic in Arms Regulations. This is an important step toward reducing the burden of regulations restricting international cooperation on amateur satellite projects, which have impeded engineering work by amateurs in the United States for decades.
Export regulations divide both technical information and actual hardware into three categories. The most heavily restricted technologies fall under ITAR, which is administered by the State Department. Technologies subject to more routine restrictions fall under EAR, the Export Administration Regulations, administered by the Department of Commerce. Technologies that are not subject to either set of regulations are not restricted for export.
On 20 February 2020, Open Research Institute (ORI) filed a Commodity Jurisdiction (CJ) Request with the US State Department, seeking to establish that key technologies for amateur radio are not subject to State Department jurisdiction. “Information and Software for a Digital Microwave Broadband Communications System for Space and Terrestrial Amateur Radio Use” was assigned the case number CJ0003120. On 11 August 2020, the case received a successful final determination: the technology is not subject to State Department jurisdiction. This is the best possible outcome of a CJ request.
The Final Determination letter can be found at
https://www.openresearch.institute/wp-content/uploads/2020/08/CJ-0003120-Final-Determination-Letter.pdf
Under this determination, the technologies are subject to the EAR. The next step is to submit a classification request to the Commerce Department. ORI anticipates that the Commerce Department will find that these technologies are unrestricted under the carve-out for open source in the EAR.
Open Research Institute (ORI) is a non-profit research and development organization which provides all of its work to the general public under the principles of Open Source and Open Access to Research.
This work was accomplished by a team of dedicated and competent open source volunteers. The effort was initiated by Bruce Perens K6BP and lead by Michelle Thompson W5NYV.
Open Research Institute developed the ideas behind the Commodity Jurisdiction request, hired Thomsen and Burke LLP (https://t-b.com/) for expert legal advice, organized the revisions of the document, and invited organizations and individuals with amateur satellite service interests to join or support the request.
ORI thanks Libre Space Foundation and Dr. Daniel Estevez for providing their subject matter expertise and written testimony, and JAMSAT for helpful encouragement and support.
The legal costs were fully reimbursed with a generous grant from Amateur Radio Digital Communications (ARDC). See https://www.ampr.org/grants/grant-open-research-institute/.
ARDC and ORI share a vision of clearly establishing open source as the best and safest way to accomplish technical volunteer work in amateur radio. This final determination letter provides solid support for that vision. The determination enables the development of implementation guidelines that will allow free international collaboration.
This clears the path for a number of interesting projects facilitating new methods for terrestrial and satellite communications, opening the door to robust global digital amateur communications.
Questions and inquiries to ori at open research dot institute.
Digital Multiplexing Transponder Workshop Guide and Link to Audio
The document linked above is a Guide to navigating the Audio Recording of the P4XT Digital Multiplexing Transponder Workshop.
The workshop was held Sunday 9 February 2020 (3PM – 7PM) at Starter Studio’s Conference room in downtown Orlando, 4.5 miles from the HamCation venue.
A full audio recording (330MB MP3) is available at https://www.dropbox.com/s/9k065i5kqj3i49w/200209_1316.mp3?dl=0.
P4XT Digital Multiplexing Transponder Project Program Proposal
Greetings all,
This is our P4XT Digital Multiplexing Transponder Project Program Proposal. It’s the result of multiple revisions and a lot of work.
We recognize Wally Ritchie WU1Y for taking on the majority of the writing duties. He has crafted quality work from a wide variety of input, commentary, argument, and critique. He has clarified our intentions and ambitions into a quality proposal.
It is ready for publication and distribution.
Current version can be found at:
p4xt_proposal
Invitation – Digital Multiplexing Transponder Working Meeting at HamCation 2020
Open Research Institute is planning a working project kickoff session for the P4XT Digital Multiplexing Transponder Project, and you are invited!
This will be a half-day session to be held just after the closing of HamCation in Orlando on Sunday afternoon, February 9, 2020.
The goal of the P4XT project is to produce open source Digital Multiplexing Transponders (DMTs) for the Amateur Radio Service Microwave Bands, including fully tested and verified hardware, hardware descriptive language, and firmware. These DMTs will be suitable for deployment in Geostationary Orbit.
This will be a working session by the participants. The first half of the session will be technical. The second half will focus on project planning and budget issues.
During the HamCation, there will be a public one-hour high-level presentation of the project. There will also be another one hour presentation by ORI on GEO amateur satellites and a presentation about open source projects across amateur radio.
The written project proposal and the agenda for the meeting will be published in advance of the session.
The session will be held near the HamCation venue. The session will be from 3PM – 7PM on Sunday, February 9, 2020.
3PM – 3:30 PM will be a meet and greet. The formal agenda will be 3:30PM – 7PM.
As this is a working session, attendance is limited. It is not intended to be an open public event but rather a working session of key potential contributors and advisors. Therefore, an RSVP is required.
RSVP to w5nyv@arrl.net or 858 229 3399 (leave a message, texts are welcome)
We will hold this session in accordance with Open Research Institute Developer and Participant Policies. These can be found at https://openresearch.institute/developer-and-participant-policies/
See you there!
-Michelle Thompson W5NYV
FPGA iCEBreaker Workshop – digital communications for amateur satellites
Greetings all!
Field Programmable Gate Arrays (FPGAs) are one of three fundamental types of digital architectures used for communications R&D.
The others are general purpose processors and graphical processing units (GPUs).
This fall, in San Diego, California, there will be an FPGA course sponsored by Open Research Institute. There are 10 spots with amateur communications as the focus of the work.
FPGAs are a primary technology in satellite communications. They’re used in R&D and in deployment. It is difficult to get started with FPGA design for several reasons. The tools have traditionally been proprietary. The companies that make the tools price them for large corporations to buy. Coursework for FPGA design is rare.
This is where iCEBreaker makes a difference.
An iCEBreaker Workshop 10 pack has been made available. They are described at this link https://www.crowdsupply.com/1bitsquared/icebreaker-fpga
I will use this hardware to put on a course for anyone interested in amateur radio satellite and terrestrial development. All course materials will be published.
The first course will be in San Diego. If you’re in the area, please get in touch! MakerPlace and CoLab are the likely sites.
Later workshops could be at places like Symposium, Xenia, or Hamcation. The full course cannot be accomplished in a day, but a workshop could get the basics across and provide a substantial boost to motivated amateur satellite engineering volunteers. Let me know what you think.
more soon!
-Michelle W5NYV
Phase 4 Ground and Theseus Cores – Video Report
Phase 4 Ground has had some good results with the RFNoC polyphase filterbank from Theseus Cores. Here’s our update on this week’s work!
Phase 4 Ground Video Report 10 May 2019
Got two minutes? Then we have a Phase 4 Ground video report for you! :+)
March 2019 Report: JAMSAT Symposium, Phase 4 Ground, and GNU Radio Companion Localization!
Phase 4 Ground and GNU Radio
My daughter Geneva and I had a wonderful time at JAMSAT Symposium in March 2019! There was a wide variety of talks about so many different payloads, a very special banquet dinner, adventures in Kyoto and Osaka, visits to ham radio stores, getting to see a new ICOM radio up close, lots of Pokemon, a Fire Festival, and making so many new friends. We were welcomed and will never forget the hospitality. A big part of Symposium was the GNU Radio Workshop by Imamura-san. It was an honor to share how we on Phase 4 Ground use GNU Radio in our presentation on Sunday morning.
GNU Radio is a digital signal processing framework for software-defined radio. It’s the software that tells the hardware in your radio what to do. We need to be able to quickly and easily set up a software-defined radio to do whatever modulation and coding we want, and GNU Radio Companion can help us do this. GNU Radio Companion is a Graphical User Interface that allows us to drag and drop functions onto a canvas. We click block outputs to connect to block inputs. When we do this, it creates a directed graph that implements radio functions. The signals flow from beginning to end. Each block modifies the signal, as if it was part of a circuit. The flow graph looks something like a block diagram combined with a software flowchart. GNU Radio has software variables. It can adapt to signal conditions and user input.
The workshop was held after the last talk on Sunday. It was several hours of hands-on training. Participants brought their own computers, installed GNU Radio, and created useful radio flow graphs that worked with real hardware. Several experiments were done in order. Imamura-san kept everything organized through a set of projected slides that had clear instructions. Optimizations and customizations were made so that participants could see how they can use GNU Radio to achieve their goals. The hardware included RTL-SDRs and Plutos. Imamura-san also demonstrated a live video transmission from the podium.
GNU Radio comes with a very large number blocks included. When you install GNU Radio, these blocks come for free! The first type of block is a source block. This brings the digital samples, from the radio hardware attached to the computer, into the GNU Radio flow graph. The second type of block is a sink block, which consumes signals. Sink blocks include things like saving a signal to disk, an audio output, oscilloscopes, spectrum analyzers, time sequences, or video. In between the sources and the sinks are all the radio functions that we need to make our radios work. Filters, amplifiers, decoders, demodulators, counters, constellations, costas loops, synchronizers, and more! You can make your own custom blocks or modify an existing block.
If you install GNU Radio using PYBOMBs, then you can add additional blocks from outside GNU Radio very easily. PYBOMBS works on Linux.
One of the most useful GNU Radio Recipes for our community is gr-satellites, by Dr. Daniel Estévez. There are a lot of satellites supported in this module. For an introduction, please see the source code repository here: https://github.com/daniestevez/gr-satellites.
The introduction also covers how to submit telemetry to the projects that have requested this.
Other great open source satellite communications projects include Dan Cajacob’s base station network, Alexandru Csete’s gqrx and gpredict programs, Libre Space Foundation’s SatNOGs (satellite network on the ground) with RTL-SDR and GNU Radio, and PE4WJ Es’Hail2 (QO-100) uplink, beacon tracker and LNB drift correction flowgraphs.
Phase 4 Ground is a broadband digital microwave system for both terrestrial and space use. It complies with both ITAR and EAR open source and public domain carve-outs, so it’s open to participation worldwide. All engineering is published as it’s created. All are welcome to participate.
Phase 4 Ground is best suited for GEO and HEO satellite missions. The uplink is frequency division multiple access. We use a 5GHz uplink. The regenerative repeater payload receives the uplink signals, digitizes them, multiplexes them, and processes them into DVB-S2 and DVB-S2X frames. The downlink is 10GHz. DVB-S2 is Digital Video Broadcasting Satellite 2nd edition. The X stands for extensions down in to Very Low SNR modulation and codings. Very Low SNR is of interest to hams, so we include the extension to the main standard DVB-S2.
We use both pilots and short frame lengths in order to make the receiver implementation as easy as possible. Pilot tones are optional, and there are medium and long frames available in the standard.
There is a recommended order to receive DVB-S2/X frames. The first stage of the demodulator is symbol timing recovery. We have to figure out the best possible time to measure the received signal. We don?t know what the transmitter clock is doing! We will not be coordinated with it. We may even be off a bit in terms of the period of the clocks, or we might have jitter, or we might have drift. We have to analyze the received waveform and synchronize our receiver clock to the transmitter clock that is ?hidden? in the received signal. Then, once we are synchronized, we sample that symbol and report the results. Doing this gives us a reliable value for the received symbol. Now that we have a series of received symbols, we have to figure out the start of the frame. This is done in DVB-S2 (and many other protocols) by sending a fixed well-known pattern at the start of every frame. For DVB-S2, this is called a Physical Layer Start of Frame sequence. It?s 26 symbols long. This is what we look for. Once we see it, we know where the start of the frame is! Frame synchronization can be done in several ways. There are two different methods described in the implementation guidelines for DVB-S2/X. One is relatively simple, using shift registers. The other is bit more complex, using state machines. There are advantages to using the state machine method, but it?s more complicated and expensive. The shift registers is simple and cheap, but gives up a bit of performance. This is the constant balance in digital communications. Performance comes at a cost!
Right after frame synchronization, we correct for carrier frequency error. First we do a coarse correction. This can be done with a delay-and-multiply frequency error detector. Then we do a fine correction. This can be done with something like a feed-forward estimation algorithm. Coarse correction is in the MHz, and fine correction is the hundreds of kHz.
Next, we do phase recovery. This is to fix any residual frequency offset from the coarse and fine frequency offsets. Phase 4 Ground will support all the modulation and codings of DVB-S2/X, but we expect lower order modulations to be more heavily used. This means that a pilot-assisted maximum-likelihood (ML) feed-forward estimator will be the most useful. If you compute the average phase of each pilot field, then you can subtract this out and improve the signal. Higher-order modulations will need another feedback loop.
Automatic gain control is next. AGC can be done in many ways. One way to do it depends on the pilot symbols in DVB-S2/X standard. These symbols are sent at regular intervals to provide a known easy-to-receive signal. We use these known pilot symbols in order to determine the amplitude multiplication factor for the rest of the signal. Pilot symbols are optional in the DVB standard, but Phase 4 Ground requires them. When the pilot symbols are on, the AGC is listening. When the pilot symbols are off, the AGC turns off, and the information from the AGC is used.
After AGC, the constellation is decoded. DVB-S2 has a lot of them! There are many techniques to get the bits from the constellations. GNU Radio has a very versatile and powerful constellation block.
Instead of the usual MPEG transport stream (DVB-S2 is for satellite TV, so the content is usually broadcast television signals), we use the more flexible Generic Stream Encapsulation standard from DVB.org. This means we have less overhead and complexity, and can handle any digital traffic that the amateur operator wants to transmit. It?s just a digital pipe.
Phase 4 Ground uses GNU Radio extensively in research and development as well as for archiving and publishing our work. GNU Radio is not just a tool to figure things out, but is also a way to define a reference design for the radio.
Because Phase 4 Ground is not a bent pipe, the payload is more complex. This complexity needs to be fully tested on the ground before risking large digital circuits in space.
All the uplink channels are received with a polyphase filter bank. The current polyphase filter bank implementation in GNU Radio needs some updates in order to achieve the speeds and performance that we want. This is an active area of research and development. There have been three efforts over the past three years by various groups that have attempted to update and improve the existing working polyphase filter bank in GNU Radio.
Ron Economos and Paul Williamson successfully implemented GSE in GNU Radio and in Wireshark. This made it possible to do transport layer testing. Ron Economos is the lead author of the DVB blocks in GNU Radio. Improvements to GSE continue today. The current focus is improving internetworking functions so that large amounts of data can be more easily handled. We intend to use multicast IP as much as possible, and making sure GSE integrates well with multicast IP is important.
The error correction in DVB-S2/X is state of the art. There are not many other error correcting codes that are better than Low Density Parity Check + BCH. This is a concatenated digital code specified by the DVB standard for S2 and T2 transmissions. We have two open source implementations of LDPC decode for DVB-S2/X. The first one is for graphical processing units and was written by Charles Brain. It was demonstrated at 2017 AMSAT-NA Symposium and at several events following. The second open source implementation is in C by Ahmet Inan and can be found here: https://github.com/xdsopl/LDPC
This version has been incorporated into GNU Radio by Ron Economos. This can be found here: https://github.com/drmpeg/gr-dvbs2rx
The next step for LDPC is to implement and publish an open source version for FPGA.
GNU Radio is very important for our voice codec work, uplink modulation experiments, and trying out authentication and authorization schemes. GNU Radio allows us to use a wide variety of off the shelf hardware to achieve things that were not possible only a few short years ago. The GNU Radio community has been welcoming, helpful, supportive, friendly, and a source of continually amazing software-defined radio advancements.
GNU Radio has an annual conference. In 2018, we held a week-long “Block Party” for DVB-S2/X. We had fun, set up multiple demos, explained DVB-S2/X, made the case for open source LDPC, and made progress on DVB-S2 correlates and GSE. Phase 4 Ground made significant progress due to the generous support of the conference organizers and the community.
Learn more about the conference here: https://www.gnuradio.org/grcon/grcon19/
Registration for 2019 is open. The conference will be held September 16-20, 2019 in Huntsville, AL, USA. There is a poster session, proceedings, talks, workshops, contests, and social activities. The theme for 2019 is Space Communications! There are special gifts for space themed content. If you have a GNU Radio project that you want to share, consider making a presentation at or sending a poster to GNU Radio Conference 2019.
One of the proposals coming out of JAMSAT 2019 was localization of GNU Radio Companion for the Japanese language. Work has begun. The first step is to make sure that all Japanese characters can be displayed in GNU Radio Companion. This means going through the codebase and removing anything that prevents Japanese characters from being freely displayed. GNU Radio project leadership is very supportive of the project. We will do our best on this! We will need help reviewing and perfecting the language support in GNU Radio Companion.
The collaboration between Phase 4 Ground and JAMSAT has been absolutely stellar and we all look forward to continued enjoyment and success. Next generation payloads will be more complicated with multiplexing and advanced digital techniques. We all need to be able to work together, internationally. Open source and public domain is the best way. Phase 4 Ground and Open Research Institute are entirely dedicated to making this happen. We will be keeping the momentum and progress going. ORI is proud to be an affiliate member of Open Source Initiative https://opensource.org/
Join the Phase 4 Ground team! Our mailing list can be found at our website https://openresearch.institute/ Write Michelle Thompson w5nyv@arrl.net to join our Slack account. This is where daily engineering discussions take place.
More soon!
-W5NYV
LimeSDR Mini Hardware Donations from ESA and MyriadRF Announced
Thank you to European Space Agency and MyriadRF for giving Open Research Institute the opportunity to get LimeSDR Minis into the hands of some very amazing people doing open source space communications research and development.
ORI and Phase 4 Ground are very proud to present the following international recipients. We commit to supporting, enabling, promoting, and publicizing their work.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sahana Raghunandan, USA
As part of discussions at the 2018 GNU Radio Conference DVB-S2X Block Party, one of the functionalities of the demodulator that was identified as needing additional review and testing was the frame synchronization and symbol timing recovery loop. The goal of targeting LimeSDR is to modify and test existing GNNU Radio flowgraphs related to this subsystem of the demodulator. In order test this functionality independently, it is assumed that signal captures at the input to the baseband demodulator will be available.
Sahana Raghunandan is a researcher at Virginia Tech and an independent consultant focusing on satellite and terrestrial systems engineering including waveform design & implementation and interference analysis for spectrum management. Her experience includes design and FPGA-based implementation of waveforms for satellite broadband modems and satellite ground systems architecture with emphasis on modeling and simulation of cross layer optimization techniques. She has also worked on platforms and architectures for software and cognitive radio networks. Her research experience also includes design of modules for radar data acquisition, system integration of radar depth sounders and application of synthetic aperture radar techniques for ice sheet tomography.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jeremy Reeve, New Zealand
Jeremy has been working on VHF and L-band LNA designs. He has been running qucs simulations to look at optimum noise matching and stability circles and the like. His goals are to contribute RF hardware and baseband/FPGA content. He expects to be able to work with his educational institution to create a project that will result in quality open source publications.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edson W. R. Pereira, Brazil
Edson is an open source advocate and extremely active in amateur radio. He implemented a GUI (SDR-Shell) for Bob McGwier’s and Frank Brickle’s DttSP SDR, has contributed code for Joe Taylor’s WSJT-X, and has been a primary contributor on many other projects.
He is a lead maintainer for the Phase 4 Ground polyphase filter bank repository and is heavily involved with Phil Karn KA9Q’s development effort for multicast IP SDR innovations and implementations.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Matias LU9CBL, Argentina
Matias is active in many areas of open source space communications. He is part of a groupworking to build a ground station design that supports a wide variety of satellite missions.
He has a SatNOGS ground station that is making rapid progress through the development portal. He is working to build and test antennas to add to this station.
He is active in his club station (LU4AA), which plans to run a station with an azimuth and elevation rotor from Yaesu, 2 crossed Yagis for VHF, and 2 crossed Yagis for UHF. Multiple fixed station will be added for remote control, and the station will be added to the SatNOGS network after it is functional.
Matias is active on SatNOGS forums and has a blog at lu9cbl.blogspot.com.
It is critically important to increase the number of stations and people involved in satellite communications from the southern hemisphere. Matias is deeply committed to publishing, sharing, and supporting others that are working in open source space communications.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Fannin, USA
David Fannin KK6DF works closely with Phase 4 Ground volunteer David Viera and wrote the code for David Viera’s LMX2594 oscillator and CW beacon project. David Viera demonstrated this system at GNU Radio Conference 2018 to great acclaim.
David Fannin has worked on a number of oscillator and SDR projects, his github account is https://github.com/dfannin, and he is committed to open source development in advanced digital communications.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Open Research Institute and Phase 4 Ground are honored to be given the chance to put advanced software defined radio hardware like the LimeSDR Mini into the hands of active developers across the world. We are ready to help make the most of this very generous donation to open source space communications work.
-Michelle W5NYV
GEO and HEO Launch Update – Phase 4 Ground Supported Payloads
We don’t like keeping secrets. However, we do have some secrets.
The Phase 4B payload, and the other related projects that we have actively supported (like CQC) all require launches.
We have a launch with the Wide Field of View payload with the Air Force. The good news is how well we did in getting engineering approval for this launch. We have a ride. The bad news is the cost of the launch. It is $6 million and they can guarantee us about one year and not even guarantee us it will be over the United States. We have decided we cannot ask the community for $6M to support this launch. It’s just not a good deal for US hams.
Fortunately there’s been a lot of work going on behind the scenes for additional launches. This work has been going on for a while.
I can’t share the details. I can say that our prospects have never been better. Anyone following along and helping the project, anyone that has been with us through a lot of challenging experiences, deserves to know that we are absolutely serious, focused, and unrelenting in obtaining multiple launches for this technology.
Traditionally, an amateur launch would be announced and then a payload developed. With modern digital technologies taking significantly longer development time than legacy technologies, and with opportunistic short-notice launches becoming more the norm, this design pattern really can’t work for us. That’s one of the reasons we need to work hard, now, as if the launch was imminent. Howie DeFelice and I wrote an article for QEX about this.
Working hard without a launch date is a lot to ask of people that are not getting paid and in some cases not being given the support or recognition they should be getting.
In the new year, we’ll be doing just that and asking for more in terms of technology demonstration and development from the team. The next big technology demonstration will be HamCation, and the most ambitious goal for that is to have LDPC working on an FPGA with interactive controls. This is the heart of the coding part of the receiver.
A GNU Radio LDPC demonstration can be seen in a recent video report, and the GPU version can be run by anyone with a late model Nvidia GPU.
Until HamCation, our goal is to get the air interface into the best possible shape. We need to capture the excellent progress we’ve made and make it as easy as possible for upcoming payloads to say “Yes!” to Phase 4 Ground.
There’s plenty going on. Progress is good. Launch prospects are part of that good news. A lot of the work is invisible during the negotiating process, but we are working as hard as we can to make it more than worth the wait.
-Michelle W5NYV
Hardware Donation for Open Source Space Communications Work – LimeSDR Mini Kits Available
Thanks to the enormous generosity of MyriadRF, Phase 4 Ground has some hardware help!
Five LimeSDR Mini Kits have been given to Phase 4 Ground for open source satellite communications development work.
We want to get these into as many hardworking hands as possible! Write me today with your need and let’s get you up and running.
I recently set up a LimeSDR Mini with GNU Radio with one of our list members and it went very well. This is a wonderful SDR. The LimeSuite GUI allows prototyping with what feels like every register setting on the controller. Performance is very good.
For a talk about LimeSDR (and the extended frequency range chip) from Microwave Update 2018 from Mike Seguin N1JEZ, please see https://youtu.be/F76BzezuCmw
LDPC-BCH decode on the FPGA is a current area of great interest for us. LDPC-BCH is the forward error correction for DVB-S2/X. But, we are also interested in doing more with Polar codes. There is at least one open source satellite payload project that has specified Polar forward error correcting codes. There is very little open source work here, it’s cutting edge, and Polar codes are specified for use in 5G communications. Polar codes are the first family of error-correcting codes that achieve the Shannon capacity for a wide range of communication channels with efficient encoding and decoding.
The FPGA on the LimeSDR mini is the Intel MAX 10 (10M16SAU169C8G 169-UBGA). How far can we take it?
What else needs doing? How about a SatNOGS station with the LimeSDR mini? A proof of concept of Phase 4 Ground authentication and authorization scheme? Handling the Generic Stream Encapsulation streams properly from the downlink for amateur communications? Plenty to do! Dive in and we will help you.
Contact Michelle W5NYV w5nyv@arrl.net to sign on and get kitted up.
Open Research Institute at DEFCON 26
Amateur Radio and open source Amateur Satellite activities at this past week’s DEFCONwere very successful.
Multiple talks across the somewhat daunting schedule provided plenty of opportunities to hear about amateur radio, open source satellites, modulation and coding, and ground station work. Phase 4 Ground had an opportunity to present at Cyberspectrum, and then helped host a Q&A the following day.
Open Research Institute had a booth in the WiFi Village Friday-Sunday. Services provided were the DEFCON ham radio license exam information/encouragement, SatNOGS information/handouts/stickers, Libre Space Foundation information/handouts/stickers, GNU Radio demonstrations and quick tutorials, FaradayRF information/handouts, SDR demonstrations, Trans-Ionospheric badges, Phase 4 Ground updates/recruitment/promotion, and more.
The landscape of amateur radio in space is diverse, interesting, and active. The audience at DEFCON is enthusiastic, positive, technical, and generally unafraid to build things and try stuff.
The Amateur Radio Relay League (ARRL) was there this year, and they are thinking about coming to GNU Radio Conference as well.
We met several university researchers and put them in touch with the right support networks to get their cubesats “off the ground”.
It’s hard work to be part of a event as large, loud, and busy as DEFCON. The attendance was estimated at 27,500 by Sunday. However, it’s very much worth it! It was great to meet so many people in person for the first time that we’ve gotten to know through electronic means.
We are solidly in the black on Trans-Ionospheric badge sales and are well on our way to funding the development board for Phase 4 Ground radios. Support and information here: https://www.openresearch.institute/badge/
We’ll be selling them online shortly. All proceeds go directly to support the non-profit ORI, and specifically for Phase 4 Ground project.
Next up: finding out how to improve representation for amateur radio on interplanetary missions from NASA. We’ll be at the Interplanetary Cubesat Workshop this week at Goddard Space Flight Center. We’ll have a poster session on open source satellite and ground station work, specifically allowed under ITAR 120.11.
Thank you to everyone that helped make this trip rewarding and fun with the encouragement, support, and materials.
DVB-S2/X Block Party at GNU Radio Conference
Hello everyone,
GNU Radio Conference is coming up in September. If you haven’t registered and want to go, please do at https://www.gnuradio.org/grcon-2018/
There’s a special event this year called Block Party.
It’s an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio.
We will have our own room and tables and swag. We will have docents enthusiasm and test equipment. We’re looking for more! We’ll have documentation and refreshments.
We need blocks!
Most blocks needed for DVB-S2/X receive do, in some form, already exist. Some do not. Some just need additional modulation and codings added to them.
Receiver design is hard, but breaking it up into small blocks makes it tractable.
The DVB protocol documents are all open. There are implementation guidelines. See https://www.dvb.org/
There are several community members that are experts in this area. There is a team (Phase 4 Ground – find out more at https://phase4ground.github.io/) that needs DVB-S2/X to work in GNU Radio. There is a lot of interest from a variety of other groups including Libre Space, ARRL, AMSAT, and TAPR.
If you are able to contribute to this effort, I want to know about it! I am here to support it. I’d like nothing better than to complete the Block Party at GNU Radio Conference with working, tested, documented blocks for a DVB-S2/X receiver. This contribution makes our open source terrestrial and space radio designs for Phase 4 Ground possible, and also opens up a lot of other work.
The thing that is considered the hardest part is the LDPC FEC decode. We have an open source implementation that targets GPUs. We want to take this and get it into RFNoC. If you are working on this as well, we want to collaborate and support and combine and promote.
The GPU implementation (by Charles Brain G4GUO) of LDPC decode can be found at our repository folder here: https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx
Phase 4 Ground is devoted to an open source implementation of DVB-S2 and DVB-S2X for amateur radio terrestrial and space use. We are part of Open Research Institute. Learn more about this non-profit here: https://openresearch.institute/
Paid Ground-Station Control Operators and Amateur Satellites
Paid personnel are not allowed to be control operator or license grantee of Amateur Satellites. In the United States, this means that a paid employee of the sponsoring organization of the satellite, for example a professor at the university that has built the satellite, can not be a control operator or the license grantee.
I recently corresponded with our IARU Divison 2 representatives regarding this issue. Thanks to Edson W. R. Pereira PY2SDR and Ray Soifer W2RS for this information:
The issue regarding paid operators is due to the definition of the amateur radio service as defined by the ITU.
ARTICLE 1 Terms and definitions
- No. 1.56 amateur service: A radiocommunication service for the purpose of self-training, intercommunication and technical investigations carried out by amateurs, that is, by duly authorized persons interested in radio technique solely with a personal aim and without pecuniary interest.
- No. 1.57 amateur-satellite service: A radiocommunication service using space stations on earth satellites for the same purposes as those of the amateur service.
- No. 1.96 amateur station: A station in the amateur service.
The same definition is used by the FCC: https://www.fcc.gov/wireless/bureau-divisions/mobility-division/amateur-radio-service
The key point here is the term “pecuniary interest” — in other words, “without financial compensation”. The definition is related to the *operation* of an amateur radio station, as you have stated in your message. Persons, including amateur radio operators, could be financially compensated to design and build amateur satellites, but according to the regulations, as they are presently written, the person cannot be compensated to operate the station.
If the station will operate under a US FCC amateur license, the control operator may not be an employee of the sponsoring organization, whether or not he is being directly compensated for operating the station. The license grantee is also deemed to be the operator of the space station operating under his license.
For those reasons, FCC licenses most Cubesats as experimental, not amateur. Experimental licenses do permit operators to be compensated. However, experimental stations may not communicate with amateur stations.
Ground Station Weekly Report #409
Welcome to the Phase 4 Ground Weekly Report!
409!
Video link
2 4 6 8 Everybody Correlate!
Correlator team had a conference call on Thursday 5 April 2018. Jordan, Brennan, Ed, and I talked on the conference bridge Ed set up for us for about 45 minutes. We covered a lot of ground and got some idea of next steps. We have a repository that has GNU Radio draft blocks that do the Pi/2 BPSK demodulation and decoding, and we need to get it working as a correlator.
We also have a correlation estimation block in GNU Radio that has an issue.
Brennan Ashton reviewed our block and didn’t see any major issues yet, and then went out to see what he could see about the correlation estimation block.
Please review Brennan’s pull request here:
https://github.com/gnuradio/
This is an attempt to solve this issue here:
https://github.com/gnuradio/
Which if successful will help us and a lot of other people.
This effort is in progress and will be updated as the code is reviewed and feedback from GNU Radio given.
10GHz Filter
We have a 10GHz filter design proposed from Jeffrey Pawlan.
It covers the 10GHz amateur band, has 0.1dB variation over the band, 0.1dB insertion loss, and 20-30dB return loss. It’s a high-performance filter and we are talking about how to get it published, how many prototypes to build, and what the potential market might be. Here’s the first four documents from Jeffrey. These are in the repository at the link in the notes. If you have feedback we want to hear it.
https://github.com/
Block Party at GNU Radio Conference 2018
We are sponsoring a Block Party at GNU Radio Conference 2018. This is a multi-day hackfest, workshop, and summit all about making an open source DVB-S2 and DVB-S2X receiver in GNU Radio. Come and help. We have five solid technical docents for the event and could use more. The goal is to bring blocks and write blocks on site, test interoperability, and leave the conference with a working DVB-S2 receiver. This is the central mission for successful continued research and development and we need all hands on deck.
If you’ve have never coded a block in GNU Radio, then don’t worry. It wasn’t until the past year that I had ever coded up a block for GNU Radio. I just had never needed to. There is a series of guided tutorials from GNU Radio’s website. The link is in the notes.
https://wiki.gnuradio.org/
Go there, or search them up with “gnu radio guided tutorials”, walk through them, and you will have the tools and the workflow experience to be able to contribute.
Having said that, if you are only comfortable coding in python or C++ then that’s ok too. If you have an idea for getting some part of the DVB-S2 digital signal processing done, and either don’t have time to work through block coding or pybombs distribution, then you can certainly still help by sharing your signal processing code. Don’t let GNU Radio block configuration stop you. You’re needed and appreciated.
KA9Q SDR – stereo field
Phil Karn has shared a work in progress with us. He calls it the KA9Q SDR. However, the module in this SDR code that I’d like to highlight is a stereo field audio adapter.
This works by taking in multicast audio streams. Each audio stream comes from an individual audio source, or participant. These participants in a round table audio conference are placed at different points in the stereo spectrum.
Phil Writes:
I’m writing a lightweight, modular SDR package that uses IP multicast
for inter-module communication. Multicasting is very flexible and
convenient for this sort of real-time application, and I really think
it should become standard practice.
One module is an audio decoder-player. I’m often running several SDRs at once so I wrote it to handle multiple multicast streams. Since several mixed audio streams can be confusing, I’ve been experimenting with ways to help the user distinguish them.
I started with a simple text display that lists the streams and their
types and sources, highlighting those that are currently active. You
can individually adjust levels or ignore those you don’t want.
Since most sources are mono, I added the ability to give each one its
place in the stereo aural image. I’m trying to recreate the famous
“cocktail party effect” that, in person, helps you pick out one voice
from several talking at once.
Audio engineers typically place a source in a stereo image with a
mixer “pan pot” that adjusts its gain in each channel. This works –
sort of. I wanted to find something better.
So I read up auditory perception. I learned that we distinguish the
direction of a sound only partly by the level difference between our
ears, as that doesn’t actually change much as your head turns. The
*real* cue is the difference in arrival time. The speed of sound is
about 340 m/s, so if our ears are 30 cm apart (measuring around the
head) that’s a little less than a millisecond.
This didn’t seem like much, but it was very easy to add these small
delays to the “pan pots” in my player. And it works! The effect is
almost eerie; you have to listen to each channel in turn to convince
yourself that the levels are almost the same.
Conference calls (or “round tables” as we hams call them) are very important in communications. I’ve long thought we can make them much better, especially in how we handle several simultaneous speakers. If we use this scheme to place each participant in a round table we should get a lot closer to that “in person” experience that’s so difficult to produce in electronic communications.
All this requires that each participant receives every other
participant as a separate stream — there’s no central “conference
bridge” that mixes everybody together. This is a perfect application
for IP multicasting. Not only can you put each participant in its
place, the status display shows you at a glance who’s talking. You can
squelch an individual who keeps disrupting the meeting, and you can
even have a private aside by sending unicast traffic rather than
multicasting to the entire group.
A lot of this was done as research in the early days of what became
‘voice over IP’ (VoIP) but it seems to have fallen by the wayside. It
really deserves to be more widely recognized and used.
Phil Karn, KA9Q
9 April 2018
Careful COTS SDR
We are making great progress on the Careful COTS re-layout of a USRP E310 with future plans to tackle the E320. We’re collaborating with AMSAT Golf on this and have gained enthusiastic support from Ettus Research engineering. The next steps are to negotiate what’s needed on the business side. Scheduling talks is in progress.
If you’re not familiar with the term, Careful COTS – COTS means commercial off the shelf – is taking something that wasn’t designed specifically for space and making it work for space environments. This is done by selection of the right components, designing in redundancy at the system level, and testing the entire system for radiation tolerance.
We have a high degree of confidence that the Ettus USRP will work and some volunteers willing to do the work. If you are interested in this part of the project, let me know.
Badge Update
The Transionospheric badge prototypes are being built at a contract manufacturer in San Diego right now. We are working hard to have them at Hamvention for sale. All proceeds benefit Phase 4 Ground! They aren’t just for show, they will be a radio peripheral for Phase 4 Ground radios, providing a lot of visual reinforcement on what your radio is doing and the health and status of your link. Whether you have a satellite or a terrestrial system, the same information will be stylishly displayed. We are working hard to make it possible to command other radios as well. More on that as it develops!
If you want to be part of the effort, then join our Slack and mailing list at http://lists.openresearch.
Write me for an invitation to Slack. All are welcome. This project is intended to spread enjoyment, appreciation, and success in broadband digital communications at microwave for amateur radio use. A lot of what we do is complex and challenging, but we are here to help and you can contribute at any level.
Thank you for all the support and interest. If you have suggestions or questions or something you think we need to know about, let us know. If all goes well, we’ll see you next week!