Saturday 23 December 2017

Gravity Simulations for Year 6/7 Students

This note discusses Python programming for year 6/7 students at a local primary school.  The activity was part of a STEM program coordinated by CSIRO.

Python provides an excellent option for introducing programming in schools and has been widely adopted in the UK.  After discussions with the class teacher, we decided to use Python within the area of Space Science.  In particular the lessons aimed to introduce the elements of programming in a Python development environment using "Turtle Graphics", with a focus on simulating the motion of heaven bodies subject to gravity.

Primary students can make very good progress with programming concepts and are keen to learn.   However the motion of bodies subject to acceleration is normally a high-school topic.  The examples below aim to show that using first-order equations can put this topic within reach of primary students.  We need the following "maths":
  • distance travelled = velocity * time interval    
  • change in velocity = acceleration * time interval
  • force = mass * acceleration 

The last equation, which is Newton's famous second law, is not actually used in the examples below but provides a great way to talk about the concepts involved, including large rockets that can provide huge thrust forces!   The second equation is basically the definition of acceleration, which might be a novel concept for younger programmers.  We are all familiar with the first equation and strictly speaking this only applies when the velocity is fixed.  Our simulation approach is to take many small time steps and calculate the object's position and velocity at each step.  As long as the velocity is changing "smoothly" this simulation approach gives a good approximation to the formulas normally used (eg s=ut + at^2/2 etc).  



Graphics output from gravity_order1.py
Anyway, two examples are shown below using this approach.  Note that to further simplify the problems we assume that the force of gravity only acts vertically and affects vertical motion, with no acceleration on the horizontal direction.

In the first example a ball is thrown upwards and falls due to gravity.  The graphical output is shown on the left.   The code (below) is very simple:  after some initialisation statements, a loop is used to evaluate the ball's vertical velocity and position at each time step.











From lander.py 

As a second example consider a lunar lander simulation, where the thruster on the lander can be toggled on and off by pressing the 'up' key. A sample output is shown on the right.  Initially the lander has zero vertical velocity and a small horizontal velocity.  It starts to accelerate towards the lunar surface due to the moon's gravity, as shown by the increasing distance between the black dots at each time step.  When the thruster is turned on, the position dots change to red.  For simplicity, we assume in the code (below) that the thruster causes an acceleration of equal magnitude, but upwards. Hence the rate of descent decreases until the thruster is turned off, after which position is shown in blue.  By toggling the thruster, the lander can be brought gently to the surface.  This takes a little practice!

It would have been nice to retain a simple simulation loop like the first example, but include a 'key-pressed' check for thruster control.  That doesn't seem possible in this environment, so the code for this example uses an 'event-driven' programming model.  The position and velocity calculations reside in function 'tloop' and the thruster is called from a key-press handling function.











Saturday 18 November 2017

Android App for RF and Optical Link Budgets


Link budgets are used in wireless communications to design parameters such as antenna sizes, bit rates, transmit power etc.  A quick link budget explains why Voyager 1 only transmits at ~ 160 bit/s, even though we use a 34m antenna on Earth to receive its signal!

About 10 years ago we wrote a java program for link budget calculations during an ISU workshop.  Here is a version of the code.  The tutorial we wrote for this application is still very relevant and discusses the effect of antenna gains, EIRP, bit rates etc.

Recently this software has been converted to an Android app.   Here are a couple of screen shots (from the initial release):

     

The LHS shows entry of some LB parameters for a cubesat downlink.  After completing all the boxes with blue lines, the "CALC" button produces outputs shown on the RHS.


Version History:

2nd Dec 2017: an updated version of this app now includes several sample link budgets, with a few comments on the parameters in each case.  These include two satellite links, one terrestrial application and a high-altitude balloon example.

Jan 2019:  Now updated to 0.5 on Google Play.   This version retains your LB parameters for re-use at a later time and includes some information on spectral efficiency.

May 31st 2019: version 0.6 uploaded to Google Play. This version includes more tutorial links, plus additional link budget examples (5G at 38 GHz, and 70cm Earth-Moon-Earth).   Users can save their own link budget parameters, with a textual description.

October 2019 version 0.7 of this app now includes Free Space Optical (FSO) communications.  Optical links are increasing attractive as RF bandwidth becomes scarcer and bit rates increase.  This version includes 3 FSO examples:  Mars to Earth, LEO downlink and an Inter-satellite link.    Version 0.71 adds one example (high rate optical downlink from LEO),  small layout improvements and updates the Android API to 28. 

Please note that this app requires a screen resolution of at least 1080 by 1920.

Oct 2022:  This video gives a very brief introduction to the Link Budget app, version 0.72. 

Privacy Policy: 

This app does not collect any information from users.  As mentioned above, recent versions of this app allow users to save their own link budgets on their own device, but none of this data, or any usage statistics,  are collected by the app.  

Monday 24 July 2017

Using FreeDV and SDR with ALSA Loopback

Introduction

FreeDV is a low bit-rate digital voice mode started by VK5DGR.  This software combines speech coding, error correction and modulation to digitally encode speech, generating a low bandwidth analog signal that is usually connected to a conventional amateur-radio transceiver.  How about using FreeDV with a SDR approach such as GNURadio plus a USRP (or similar device) - how should FreeDV be connected in this case?

Interfacing Options

One approach would use the FreeDV packages on the command line and simply pipe signals between software modules.  This can work very well (eg this example) but has the disadvantage that graphics and related GUI controls might be lost.

FreeDV running in a PC normally used 2 sound cards  - one for the mic/headphone connections and another for the low-bandwidth modulated signals.  GNURadio of course offers audio interfaces.  So we could imagine a PC with 3 sound cards, with the low-IF modulated signal from FreeDV output from SC#2 and then looped back into SC#3 as the GNURadio source. Apart from the extra hardware, that is not a good idea as the additional A/D and D/A operations would probably cause significant degradation.  But we can do the equivalent loopback operations within the PC using digital streams, as shown below.



Sample Implementation using ALSA Loopback

I thought it would be easy to setup the above on my Ubuntu 16.04, but it took a little longer than expected.  This approach uses the ALSA loopback device which is created by "sudo modprobe snd_aloop". You can see information about sound interfaces by using "aplay -L" or "arecord -L". This loopback contains multiple streams and to achieve the signal flow shown above, the loopbacks can be given names associated with specific card, device and subdevice numbers.  These names can then be used in FreeDV or GNURadio. (This page gives useful example information regarding ALSA device architecture.)

The loopback streams can be defined in the .asoundrc file.    I used the following:

# ALSA config in .asoundrc for freedv <> gnuradio audio streams
# We assume that the "Loopback" card exist and that for each
# subdevice, a signal input on device 1, comes out on device 2
# The mic and headphone interfaces are not included in this 
# file description - it should be possible to use standard names. 

# LB out #0 - to route freedv mod output to gnuradio input 
pcm.LB00 {
   type plug
   slave.pcm "hw:Loopback,0,0"
   }
# LB in #0
pcm.LB10 {
   type plug
   slave.pcm "hw:Loopback,1,0"
   }

# LB out #1 - to route gnuradio output to freedv mod input 
pcm.LB11 {
   type plug
   slave.pcm "hw:Loopback,1,1"
   }
pcm.LB01 {
   type plug
   slave.pcm "hw:Loopback,0,1"
   }

Let's assume you have FreeDV version 1.2 installed and running.  Use the "Audio Config" tool to setup connections shown in the figure below.   So select the LB01 device "from radio" under the Receive tab, and the LB10 device "to radio" under the Transmit tab.  Likewise the appropriate audio devices can be named in the grc setup.



This GNURadio diagram below shows a very simple audio loopback, with a variable amount of added noise. Notice that the audio source is setup with device name LB00 and the audio sink from GNURadio has device name LB11. During this simple test, with both FreeDV and GNURadio running,  the SNR can be varied and the effect observed in real-time on audio quality, sync etc

Of course for a real application the grc flow-graph below would be replaced by SSB transceiver processing, since that simply translates and interpolates the audio signal to a sampled signal suitable for the SDR interface.  I have a B200 USRP which I have used with GNURadio for initial SSB tests on 70 cm.  The next step will be to try my previous grc software with FreeDV.  (BTW GNURadio also includes a Codec2 module!)

Please Note
For reliable operation I had to stop PulseAudio while running the FreeDV/GNURadio test described above. Possibly there is a way of avoiding this.  Also note that "pulseaudio --kill" will respawn unless you adjust the default setting, e.g. with a .conf file that includes "autospawn=no".   It is probable that PulseAudio modules can be used instead of snd_aloop - I haven't explored that path.