Profile cover photo
Profile photo
Michelle Thompson
engineer, burner, ham (W5NYV)
engineer, burner, ham (W5NYV)


Post has attachment
Low Density Parity Check decoding is working for DVB-S2, DVB-S2X, and DVB-T2 in GNU Radio, thanks to the efforts of Ahmet Inan, Ron Economos, and Charles Brain. This is a big step forward for Phase 4 Ground and open source satellite communications.
Add a comment...

Post has attachment
3D printed Cassegrain antenna for 122Ghz amateur radio!
Add a comment...

Post has attachment
Add a comment...

Post has attachment

Workgroup 2 - SatNOGS
Open Source CubeSat Workshop

One of the activities at the Open Source CubeSat Workshop 2018 was a set of working groups. These small groups met after the presentation sessions on both of the two days of the conference. The working groups lasted between 60 and 90 minutes. Each working group had a topic or question. Discussion was free ranging, encouraged, and productive.

This working group was chaired by Manolis Surligas, a member of the SatNOGS core team responsible for software development for client and gnuradio.

The goal was information gathering from the community in order to improve SatNOGS.

The central questions of this working group were:

What is your experience with SatNOGS?
What needs to be improved?
What do you expect from SatNOGS?

A contingent of librarians and astronomers were present in this group. They explained that they found the waterfall, images, sound files, and sets of hex numbers to be confusing in two ways.

First, "observations" do not equal "data" in their field. "Observations" are the act of taking the data. Second, there was a lot to SatNOGS software that wasn't defined or placed in context. It was hard to figure out why the functions and data were cool and why one would want to use or have them. There was an unmet expectation of a tutorial.

As SatNOGS grows, the number of people outside the traditional populations will grow. Those traditional populations include amateur radio operators. Radio amateurs are in general familiar with antennas, waterfall displays, Keplerian elements, call signs, and so forth. The documentation and instructions are written, in general, for this population that has a particular technical background.

In order to scale up into communities and populations that may not have the traditional SatNOGS background, a guided tutorial can help bridge the gap. A guided tutorial may include basic definitions, expansions of acronyms, workflow, and an explanation of rotator vs. non-rotator stations.

Current instructions assume everyone approaching SatNOGS is interested in and enthusiastic about building. The astronomer or data scientist may be much more interested in the data produced than in the build process.

Some of the participants were confused about how to find out the purpose of the CubeSats in the database. The functions of the payloads did not appear to be listed. This would be very useful information for people looking for particular telemetry streams.

To build a station, it was unclear where to start. The point of entry is assumed to be relatively high in terms of skill sets. A guided build would fill this gap.

"How to build SatNOGS for normal people" was a suggested web page.

Manolis explained that the development team understood the stations to have become too Raspberry Pi centric. This is being addressed. The station needs to be modular in terms of processor, SDR, and all other major components, and if the station is too dependent on one particular architecture, then extending and adapting becomes difficult.

At what point does the Raspberry Pi saturate or become unusable when the SDR is upgraded? Are there any benchmarks for this?

Binary packages for SatNOGS are a development team goal. Ubuntu Snaps, pip, and apt-get install SatNOGS were mentioned as desirable deployments.

Installing and configuring the software, building the hardware, learning how to configure the station through the bring-up process, deploying a station, maintaining a station - these are all non-trivial tasks.

The success of the network is notable. SatNOGS went from 10 stations a year ago to over 100 stations at the conference. In order to scale further, the stations must achieve fully automated status. Having any people in the loop (more than absolutely necessary for debugging or development) is a big problem for scale. SatNOGS core team is keenly aware of this.

Kitting was discussed. Kits of SatNOGS stations would increase the rate of deployment. When Manolis asked the group if kits were of interest, there was a strong positive response. SatNOGS core team viewed kits as a positive addition to the network and it had come up in previous discussions.

I took the action item to reach out to TAPR ( to explore whether or not TAPR could support SatNOGS with station kits. TAPR offers productization, a store front, bridge capital, communications resources, a history of supporting open source kit sales from a variety of amateur radio sources, and an active membership fully in line with the interest profiles of SatNOGS station and network builders. TAPR just commenced a collaboration with space scientists to study the ionosphere, and there is great potential in finding ways for the SatNOGS network to participate in this scientific endeavor.

It was emphasized that stations close to each other are not "in each other's way". Having multiple stations in close geographical area means that each station can be assigned to watch for a different payload. It is a misunderstanding that once a place is covered by a station that another one close by is of lesser value, or competes against local stations.

The cost of the stations was discussed. Some of the participants believed that the cost guidance on the SatNOGS website was a bit low. The group settled on guidance of "expect to pay $60 for a static station and $200 for a rotator".

Manolis asked if anyone was designing SatNOGS into a CubeSat project, and the answer from some members of the working group was yes.

Manolis asked if there was any difficulty in finding whether it could support your type of telemetry? The answer was somewhat muddled by an intervening discussion of what it meant to be part of the telemetry library in SatNOGS, and how that process was handled, and the level of frustration SatNOGS developers had experienced in the difficulty of getting CubeSat communications cooperation from some missions. In general, the participants that were already familiar with SatNOGS network found it easy to figure out how they could include their type of telemetry or communications protocols, and the people that were not already familiar with SatNOGS network found it to be difficult. This is an area of potential improvement.

In general, if the telemetry used by a CubeSat team matches up to an open standard, it's probably already in the SatNOGS software.

SatNOGS can produce some very lovely graphs in real time. Access is under the developer tab. This was news to some operators, who had no idea this tab existed and the screens were available to them. This is a possible opportunity for an improvement to the UI or instructions.

For some operators, it is hard to tell how powerful SatNOGS stations are without someone walking you through it. This is an opportunity for a video walkthrough.

UPSat was discussed. SatNOGS was of great value in troubleshooting right after launch. The value is not only in being able to have the telemetry from the science payload. Knowing that there's a problem when your CubeSat is over some other part of the globe is high-value knowledge. There was one participant that did not agree, since they "couldn't do anything about it anyway."

Being able to set the priority of observations was discussed. Stations owners may be keeping back their stations from participation in SatNOGS because the owner does not want to lose the ability to prioritize the missions they are most interested in. By not joining, they can point at whatever they want to whenever they want to.

Gamification and paying people to point at stations that are underserved was discussed. Games are motivational and points, awards, levels, swag, monetary compensation, bonus bling, and plenty of other things can motivate stations to compete to cover more of the search space.

De-conflicting observations, handling special requests, scheduling the "best" observations based on a variety of objective functions, time-frame band sharing, priority lists, machine learning, and scheduling future time slots were suggested.

Calibrating the link quality of stations or "learning" the local environments (buildings blocking sight lines, local frequency dependent interference, curfews) was discussed. Characterization of stations, elevation and azimuth keep outs, polar plots, noise floors, and other very interesting statistics were discussed.

What came through during this part was how much statistics already exist in SatNOGS, and how close the system currently is to being ready for extremely powerful data fusion. The station dashboard is advanced and useful. More people using it means more interesting things found, more connections made and more data science done.

Manolis asked the group "What do you expect from SatNOGS?

To participate in the community.
To give back and contribute to the community.

There is an IRC and there is a community forum. Some of the participants were not aware of it. Improved "How to get in touch with us" web resource was requested.

A highly visible link to the observation database was requested.

A form where one could submit about their mission in order to start the process of inclusion. Satellite owners need to be able to reach out easily.

Device, RF gain, etc. is in the metadata. Ambient data from the network offers a potential wealth of leverage in answering a wide variety of space communications questions.

Advice from Manolis to the participants that did not have a traditional (radio amateur) background was to start out with a simple static station and upgrade parts to a more complex dynamic (tracking) station, instead of starting out with a complex build from the beginning.

There was a series of questions about how to get an arbitrary antenna into the program, how to use predict, how to use SDR sharp, and how to convert images. Weather satellites are an active area of a lot of interest and development.

There was a series of questions about how to integrate rotating antenna systems. In general, if it can be handled by RotCtl, then SatNOGS already knows how to handle it.

The process of getting a station included in the network is: Build, register, passkey, testing mode, install gnu radio, install gr-SatNOGS, select SDR, enter production mode.

Higher frequencies and more SDRs in SatNOGS are the goal, and is the primary reason that Phase 4 Ground attended the Open Source CubeSat Workshop. This was an excellent working group that resulted in a lot of great feedback for SatNOGS as well as substantial information and support for the community members present.

Corrections, additions, and expansions welcome to
Add a comment...

Open Source CubeSat Workshop - Workgroup 1
20181001 by Abraxas3d
One of the activities at the Open Source CubeSat Workshop 2018 was a set of working groups. These small groups met after the presentation sessions on both of the two days of the conference. The working groups lasted between 60 and 90 minutes. Each working group had a topic or question. Discussion was free ranging, encouraged, and productive.

The concern in this working group was one of process within community. Wisdom is communicated through the accumulation of best practices within a group. Any particular community, facing any particular challenge or threat, must provide members with a set of policies, procedures, goals, and rewards that give individuals the best chance of individual success. That success must also be in alignment with group goals. Community success is when the individual achievements result in collective achievement with minimal loss.

A useful analogy for understanding this balance between individual and society is impedance matching. A particular community must provide impedance matching between the center-of-mass-of-current-membership to the particular problem space those members live within and encounter and are organized to address. This gives that community the best possible chance to survive and succeed in the larger ensemble of civilization. This is dynamic over time, so goals and strategies do shift and change.

The question of this particular work group was relevant and interesting, since it directly confronted some growing pains resulting from recent community success.
There have been large steps forward. UPSat in particular has succeeded as an open source satellite. Documentation, while not completely perfect, exists and is extremely useful. The documentation is of more than sufficient quality for other teams to not have to start from scratch.

The central question is Why aren’t more new teams taking better advantage of the lessons that Libre Space has to offer?

Why does it seem that cubesat teams generally seem to start over from scratch at the beginning, wasting time and failing to take advantage of the substantial leverage that existing open source work can provide?

The perception of the host and the clear majority of the workgroup participants was indeed that too many teams were showing up, starting from scratch, and wasting time. The lessons learned and documented from UPSat should be more widely adopted. The starting point for open source space efforts no longer needs to be proprietary secret tribal lore, nor does it need to be re-learned every time by every open source team, painfully, from the beginning. Progress has been made and progress should be taken advantage of.

The group identified some potential reasons for why new open source teams start from scratch.

1. They are unaware of existing open source work.
2. They are aware of existing open source work, but lack confidence in using it or feel they don’t have permission to use it. Sometimes there is the perception that the team has to prove their worth in some way in order to access the work.
3. The team is prevented from using the open source work by an authority figure. The authority figure (e.g. a professor at a university) views using open source work as anti-pedagogical or cheating or unethical. Starting from scratch is virtuous. Starting from scratch confers credentials through an arbitrary educational process where objective achievement may be secondary.
4. The team cannot comply with the open source license. They want to commercialize the work or benefit from the work in some way that is in conflict with the open source license or culture or constraints.

The group discussed the particular challenges from a pedagogical point of view.
There is and should be a balance between legitimately learning the ropes through valuable personal experience and getting a boost past very boring basics.

When the goal of an educational endeavor is to learn something, anything, then there is no special advantage from open source work. Open source work allows the starting point to be substantially further along in the complexity curve in any given field. The further along in the starting point along the complexity curve, the harder the educational professional has to work in order to take full advantage of the material.

The educational professional either has to abstract things down, or work harder to make sure that the students understand enough prerequisites that they can handle the material. Either one of these endeavors substantially increases the educational workload. Increased workload is not to the benefit of the educational professional; they are unlikely to engage in anything that results in an increased workload, regardless of how much it may benefit a critical technology.

When the end result of an educational endeavor is given more weight than the learning-the-hard-way experience, then the head start that quality open source work provides becomes much more valuable. Open source non-differentiating technologies are enormous force multipliers to measured end results. The lessons learned being further along the complexity curve are also valuable. It is the choice of the educational professional as to where on the complexity curve they choose to start their students or team or class.

This appeared to be the crux of the discussion. The host posited that the scientific and mission success of a particular CubeSat team is of higher importance than a stereotypical learning something, anything, it doesn’t matter if the mission fails pedagogical approach. The administrative and educational leaders of many new cubesat teams may not value the success of the mission above the “pay your dues” cubesat team experience.

This dichotomy is important to Libre Space and was addressed in discussion.

This is a marketing and cultural challenge to Libre Space. Libre Space can provide a higher baseline to those teams that want to take better advantage of it. Not all teams will want to take advantage of it. Libre Space should not spend inordinate amounts of effort attempting to change minds that do not value the results higher than the pedagogical journey. The success of teams that do take advantage of the open source work will be more than proof enough, and the energy should probably be expended there.

Industry groups often provide similar functions. The central function of an industry group is how to best communicate something that is often described as “tribal lore”, to the benefit of the group members.

Documentation is not sufficient in and of itself. The best possible documentation cannot alone give enough support to new teams to start from a higher level. There are a lot of things that need to be communicated that cannot be simply written down in a table or paragraph.

Reinforcement through encouragement, repercussion, exclusion, and reward are hallmarks of industry groups.

Some of the institutional methods proposed to address the shortcomings in onboarding new teams were discussed. Most prominent was the establishment of weekly conference calls. These calls would be with any new teams that Libre Space found out about or that found out about Libre Space.

An open invitation to weekly conference calls was discussed at length. The existence of weekly conference calls to coordinate any new teams was considered to be success criteria by the host. The group valued the existence of a culture where new teams would feel willing and able to participate in regular conference calls with the open source space community. The new team would rapidly accrue the knowledge and tools and advice and support in order to get much further ahead than if they did not have this community resource. They would then be expected to contribute back in some way.

Publicizing the many successful projects of Libre Space and the wider community was discussed. The great value of the viral ideas of open source space projects was emphasized, and the need for better marketing was highlighted.

The host collected names and contact information for the attendees.

Add a comment...

GNU Radio Conference will be 16-20 September 2019 in Huntsville, Alabama. There will be significant focus on amateur satellite and space technologies at this conference. NASA tours, space communications keynotes, an amateur radio licensing session, a large vendor expo, space swag, and much much more.

GNU Radio Conference has over 50 speakers from across a very diverse community, poster session, conference proceedings, multiple intensive workshops, tutorials, and a developer summit where you can work directly with the developer team to give feedback and find out how you can participate, benefit from, and contribute to GNU Radio.

Steve Conklin and myself are the co-chairs for 2019. We will be backed up by a wonderful team of positive hard-working volunteers. We enthusiastically support the goals of the GNU Radio Foundation leadership. We are immensely grateful for this opportunity to contribute to such a vibrant and wonderful community.

The event runs Monday-Friday. Ticket price (not yet set) includes access to everything, breakfast, morning break, lunch, and afternoon break food. Two evening social events are included.

Attendance is 300+ people. All talks are recorded and posted on the GNU Radio YouTube channel. Conference proceedings are in PDF and are completely free to download.

The event is run entirely by volunteers. There are no paid GNU Radio Staff. The event is paid for by ticket sales and corporate sponsorships.

We have made multiple attempts to co-locate GRCon with TAPR DCC, ARRL meetings, IEEE, Microwave Update, and AMSAT-NA Symposium. When the events are not in conflict, attendance at the smaller amateur events goes up, and the average age goes way down. This is especially evident when the conferences are located near each other so that people are not forced to choose just one. The benefits to co-locating conferences to all communities would be enormous and bilateral. Each conference would have a separate ticket and would have a separate schedule, but share social events, expo area, poster session, and possibly the keynotes.

While this goal of a "space and digital ham superconference" hasn't happened yet, we have been much more successful over the past year in avoiding date conflicts, and the benefits can be clearly seen in attendance and feedback and greatly increased cooperation with some of the conferences. Several major initiatives are being discussed.

If you are interested in volunteering to help make GRCon2019 the best possible conference for amateur space communications, then get in touch with me (Michelle Thompson W5NYV). We are well underway for planning for 2019, and early planning for 2020 has begun. The site and date for 2020 has not yet been set.

Here are some of the amateur radio activities we're working on for 2019 and need more volunteers sooner rather than later:

Wireless Capture the Flag Contest (with Space Comms included)
Amateur Radio Special Event Station and Demonstration
Open Source Small Satellite and Ground Station Workshop

-Michelle W5NYV
Add a comment...

Post has attachment
Come dance with us at the Block Party at GRCon2018!
Add a comment...

Post has attachment
Come dance with us at the Block Party GNU Radio Conference 2018! Haven't registered? It's not too late! Phase 4 Ground will be in Sierra C at the Henderson Convention Center all week with a lab, docents, mood lighting, swag, & enthusiasm! Goal? Blocks for DVB-S2/X receiver in GNU Radio.
Add a comment...

Post has attachment
Wait while more posts are being loaded