Meteor M-N2 Images

Tuesday, 17 January 2017

VLF/LF Receiver implemented in microprocessor - Rotary encoder control and LCD (Part 4 of n)


The rotary encoder control works by switching between screen buttons on each push of the encoder button. The button that is activated is highlighted in blue when active, non-buttons that have actions are highlighted in red. Turning the encoder clockwise or anti-clockwise will change the option and activate it immediately. When the station name is red you can tune manually (the station name will change to 'User' after the frequency has been changed).

Having reviewed my code it is difficult to describe in detail exactly which changes need to be made to add rotary encoder control. However, as far as I am aware I have put a comment including the word 'rotary' in every place where I have added code for this reason. 

If you want to backport the rotary encoder code to the STM32F4 board I suggest you search all the code for the word 'rotary' - grep -r rotary * - and take it from there.

There are three main additions of code to support the rotary encoder. There is a:

  • new routine in SDR_initPeriphs.c called  initEncoder()
  • new routine in main.c called ManageEncoder()
  • new routine in stm32f7xx_hal_msp.c called HAL_TIM_Encoder_MspInit()
  • an additional section in the HAL_GPIO_EXTI_Callback routine in stm32f7xx_it.c
  • Elsewhere various variables are defined in main.h and Globals.h.


Adding the external LCD involved a lot of digging around in low level LCD controller code. It must have affected my brain because now I cannot see what I changed to make it work. There's some pin definitions for the LCD in main.h, maybe that's all it needs but I am sure the STemWin GUI controller is defined somewhere. If you want to look into this area then the file LCD_X_8080_8.h would be a good place to start. 

A video of the rotary encoder/LCD combination will be posted here shortly.

The code is available on github link



Monday, 16 January 2017

VLF/LF Receiver implemented in microprocessor - Hardware Configuration (Part 3 of n)


This post assumes that the RF pre-amp and audio out circuits have been built as described by I2PHD in his original paper found under the ARM Radio section of his website.

Microprocessor - STM32F746-Nucleo board.
LCD - ILI9341 driver, looks the same as this one 
Rotary encoder with integrated push switch

My code uses the following pin connections:

Component Pin  STM32F746 Pin
LCD_D0                 PC0
LCD_D1                 PC1
LCD_D2                 PC2
LCD_D3                 PC3
LCD_D4                 PC4
LCD_D5                 PC5
LCD_D6                 PC6
LCD_D7                 PC7
LCD_RST              PE2
LCD_CS                PE3
LCD_RS                PE4
LCD_WR               PE5
LCD_RD                PE6

Rotary encoder clockwise         PB4
Rotary encoder anti-clockwise  PB5
Rotary encoder centre              GND
Rotary encoder push button     PA0

RF In         PA3
Audio Out  PA4

In the next post I will describe the code I have added to support the rotary encoder functionality as well as the changes to the screen layout.

The cide is available on github link

Sunday, 15 January 2017

VLF/LF Receiver implemented in microprocessor - Introduction (Part 1 of n)



Alberto, I2PHD, developed a VLF to MF receiver entirely in a microprocessor utilising the STM32F4 Discovery board. I was intrigued by this so I purchased a STM32F746 Discovery board. The F7 board uses the faster ARM Cortex M7 processor rather than the M4 processor used in the STM32F4 range of boards.

However, I soon found that the STM32F7 Disco board does not make the same GPIO pins available to use. Specifically only the third analogue-digital converter (ADC3) of three is available to use. Alberto's design uses ADC's 1 & 2 in double buffered mode and this approach is fundamental, consequently I realised that I would not be able to use this board for the receiver. By the time I had worked this out ST had released the STM32F746-Nucleo board, this board is similar to the Discovery board except it makes all the GPIO pins available to use but it does not have a built in LCD display.

I was not able to compile the source code written for the F4 board for the F7 board. Whether this was through my lack of experience or for some other reason I do not know as the code is meant to be compatible between the two devices. Subsequently, I proceeded to rewrite the code to use the Hardware Abstraction Layer (HAL) provided by ST. Due to the fragmented and incomplete nature of documentation for the HAL a great deal of experimentation and trial & error was involved. However, this did mean that my understanding of C programming for embedded microprocessors and associated debugging using gdb increased quickly.

Currently the status of this project is as follows:
  • Code for STM32F4 ported to work with the STM32F7 devices using HAL firmware library version 1.3.0*
  • To overcome the lack of an LCD on the Nucleo board an inexpensive LCD was purchased on ebay which uses the ILI9341 LCD controller and this was integrated into the code.
  • To overcome zero documentation on how to use the touch screen capabilities of the LCD I bought I implemented control using a rotary encoder.
  • I have added a spectogram function which shows a display of the signals being received - this is a work in progress.
* I have looked at using the newer 1.5.1 HAL firmware but there have been significant changes made to the operation of some of the functions and I don't intend to rewrite the code to handle these at the moment.

The picture at the top of this post shows the receiver receiving the MSF time signal on 60kHz.

I plan a series of blog posts to document this project. My plan is for posts covering the following topics:
  • Setting up the development environment - using Eclipse IDE, GCC compiler, OpenSTM32, gdb.
  • My implementation and the hardware connections, particularly covering the LCD and rotary encoder.
  • Specifics around the rotary encoder control and the LCD.
  • The spectogram function.
  • Wrap-up, including some problems I have yet to overcome.
The code is available on github link

Sunday, 7 June 2015

Transmitting video with a HackRF Blue

Picture of the video of my garden transmitted by my HackRF Blue
In the UK much digital amateur television (DATV) is transmitted using the DVB-S standard. This is the standard used in Europe to transmit standard definition satellite television.

Eventually I aim to transmit video through my local DATV repeater. What I have done is to prove the feasibility of using a HackRF Blue to act as the radio frequency part of the system.

I have drawn a diagram showing the individual components I used and I will go on to describe each in more detail.
Camera
I have used a standard DV video camera (Canon MV450i). It is possible to substitute this for a standard webcam. 

Computer
I use a 4 core Intel Core i5-2400, 3.10GHz CPU with 4Gb of memory. Operating system is xubuntu 14.04.

dvgrab
This software is used to grab the DV stream from the Firewire port that the DV camera is connected to. If you use a webcam then it is not necessary to use this program. It can be installed from the Ubuntu Software Centre or via the Kino pages.

ffmpeg
ffmpeg is used to convert the raw video stream grabbed by dvgrab into an MPEG-2 transport stream. If you are using a webcam you will need to change the parameters for the input source and the input video codec. It can be installed from the Ubuntu Software Centre or from the ffmpeg site.

The output from ffmpeg is sent to a fifo file to be consumed by the gnuradio program.

gnuradio
I have gnuradio installed via pybombs and am currently running version 3.7.7. Ron Economos has written the gnuradio blocks to enable DVB-S to be transmitted. You will need to download & install these from github. Included in the download is a gnuradio-companion flowgraph. Open this in gnuradio-companion to verify that you have installed the DVB-S gnuradio blocks in the correct place. If blocks show up as red then you haven't. However, Ron's code does not use a HackRF so I have changed the output sink to be a HackRF. You may also want to change the input to be a mpeg-2 transport stream file for testing and/or to reflect the location of the fifo file on your system.

You can download my HackRF version of the transmit program from here and edit it to change the reference to the directory I used for my fifo file to the one on your machine.

Example commands

One off commands

  • mkdir ~/dvb-s
  • cd ~/dvb-s
  • mkfifo mpeg2.fifo

Command to run dvgrab and ffmpeg

cd ~/dvb-s

dvgrab - | ffmpeg -re -thread_queue_size 1000 -i /dev/stdin -vcodec rawvideo -f alsa -i hw:0,0 -acodec mp2 -s 640x480 -r 25 -b:v 2M -minrate:v 2M -maxrate:v 2M -bufsize:v 1.4M -ac 2 -b:a 48k -mpegts_transport_stream_id 1025 -mpegts_service_id 1 -mpegts_pmt_start_pid 0x0fff -mpegts_start_pid 0x0121  -muxrate 2M -f mpegts -y mpeg2.fifo

I suspect that some of these parameters are surplus to requirements but these are what worked for me.

To use a webcam remove "dvgrab - |" from the start of the line and substitute "-i /dev/stdin -vcodec rawvideo"  with "-i /dev/video0 -vcodec mpeg2video"

To test that this step is working you can use mplayer to consume the video feed from the fifo file:
mplayer mpeg2.fifo

To transmit the video stream open another terminal window
cd ~/dvb-s
./dvbs_tx_hackrf.py

The transmission looks like this when received by gqrx on another HackRF.



How to receive the signal.

I used a standard DVB-S satellite TV receiver. However, these use an LNB which mixes the 10/11GHz signal with a 9750 MHz (or 10700 MHz) local oscillator (LO) to produce a signal around 1000-1250 MHz. In this case we do not use the LNB but connect an antenna directly to the input port where the LNB usually connects. 

WARNING: the antenna port has 13/18 Volts on the centre core. Do not allow your makeshift antenna to short across the inner and outer of the antenna port or you may damage your receiver.

In my example I have the HackRF Blue transmitting on 1000 MHz. I set the receiver to receive on 10750 MHz. As the LO is at 9750 MHz, 9750 plus 1000 = 10750. You need to know the LO your LNB is using (it is normally marked on them or try both values). So, I set the satellite receiver to scan for a signal on 10750 MHz. 

The other value the receiver needs to know is the symbols/second value. In the gnuradio program I have set it to 2 million symbols/second. Most satellite receivers will receive a minimum of 2m sym/sec, and this is the value you need to set in the receiver (or 2000k sym/sec). FEC can also be specified but my receiver set this to 'AUTO'.

Antenna

My satellite receiver is located underneath the television in an adjacent room to my study. Due to the use of a dummy load the transmission can only be received if the antenna from the satellite receiver is close to the dummy load. I used a length of satellite co-axial cable long enough to reach between both rooms, terminated one end with a F-type plug to fit the antenna socket of the satellite receiver. At the other end I connected the inner core of the co-ax to the driven element of a 1296 MHz beam I made recently. The outer core I taped up with insulating tape to ensure that it was not going to short to the inner conductor.

I haven't tried this but if you expose 7.5 cm of the centre conductor having cut back the outer sheath, the outer shield of copper and the inner dielectric (taking care not to short the inner and outer conductors) this should work as a quarter wave antenna at 1000 MHz. You will probably have to hold it very close to the dummy load connected to the HackRF Blue to receive the signal. 

WARNING: Wrap the centre conductor you expose in insulating tape to prevent accidental shorting as there is still 13/18V on the centre conductor.

With my 23 cm beam pointing at the dummy load I was able to receive the signal about 5 metres away.
 
References

Explanation of the ffmpeg parameters here and here.

Details of transmitting DVB-T using a webcam here.

Legal advisory

It is illegal to transmit on radio frequencies for which you do not possess a valid licence issued by your government. I hold an amateur radio licence so am allowed to transmit on a set of defined frequencies. However, for this experiment I transmitted into a dummy load, meaning that the transmission was not radiated more than about 3 metres.

For more information on becoming a radio amateur please contact your national amateur radio organisation. See the list here.

The small print

If some or other part of this doesn't work for you please don't send me a curt email saying "It doesn't work". It works for me on my system so try and understand why it doesn't work and adapt it to your environment.

Saturday, 25 April 2015

Meteor M-N2 reception with a HackRF


If you've got a HackRF you can easily use it to receive pictures from weather satellites in low earth orbit without tracking antennas, just like the one above (NB. the two thick black lines are a fault with the spacecraft and not with my reception!). NOAA have several LEO weather satellites in operation but these only transmit an older, lower resolution picture. The newer NOAA satellite had a problem which means that it does not transmit in the VHF frequencies.

However, the Russian satellite - Meteor M-N2 - is operational transmitting LRPT in the 137 MHz band.

There is a method of receiving these pictures on Linux using cheap RTL dongles (there are also methods on Windows which I will not cover) and I have adapted this method to work with the HackRF. Specifically I have also moved the receive frequency of the satellite away from the centre frequency the HackRF is tuned to. This avoids the centre DC spike and associated problems.

In the UK the satellite band is very close to wide area pager frequencies, this leads to considerable breakthrough of pager transmissions into the very weak satellite signals. This interference causes the couple of yellow and blue lines in the image above. What I have found is that this method of reception with the HackRF is much less susceptible to pager problems that when using an RTL dongle. It is also more sensitive compared to my RTL dongle leading to images received to lower elevations (where the signal is weakest).

The GNUradio program I have adapted is available here. Of course, you will need GNUradio installed (if you have a HackRF you presumably already do!)

You will find reference to my home directory in it which you will need to change first, and also make it executable chmod +x meteor_qpsk_rx_hackrf.py

Then simply run it by typing ./meteor_qpsk_rx_hackrf.py from the directory that you copied it into.

When you are receiving the satellite it helps to adjust the PLL Alpha slider on the QPSK constellation window to lock onto the signal (with the four clusters on the constellation) and when lock is achieve to move this slider to its minimum setting. With no signal the constellation should look iike this:






When the satellite is close I see a spectrum like the screen shot above, and the constellation like the screen shot below.



To work out when Meteor M-N2 is going to be nearby use the GPredict satellite tracking program.

Once the soft symbol.s file has been received using this program then it is time to open Oleg's LRPTOffLineDecoder program to produce the image. This is a Windows program but runs well under Wine in Linux.


The image above is a part of the window of Oleg's program. 
  • Click the "72k" button (as the satellite is sending data at a symbol rate of 72k but it has also sent at 80k).
  • Navigate to the place on your hard drive where the .s output file from the GNUradio program is stored, select the file and click ok.
  • You should see the two progress bars start to move and the constellation of the received signal show in the top left hand side of the window.
  • This step can take some time. 
  • If the image can be decoded the infrared/visible channels received will be shown to the right hand side.
  • Click "RGB" to generate a false colour image, you need to select the RGB drop down lists to correspond to the wavelengths that were received otherwise you will just get an all white or black image. You can also change the RGB settings to change the colouration of the image. At this point you can also save the image.
Oleg's website has other examples of images received plus links to the software etc. You can see other images I have received here.

NB: for nightime images only the infrared wavelength is usable (normally 10.5-11.5) so set the RGB settings all to 10.5-11.5. To achieve an image you can make sense of you will need to load the resulting image into GIMP and flip it horizontally, flip it vertically then invert the colours. Then adjust the contrast and brightness to bring out the land/sea by trial and error.

The image below is a night time image. This has not been rectified to take out the curvature of the earth as the image at the top of this post has.



The best antenna to use is a QFH, this link has details of how to build one. However, you could use a Crossed dipole, egg-beater (really!), or a simple quarter wave. You will receive something on a good overhead pass on a quarterwave or an amateur 2 metre antenna but don't expect images like the ones on this page. Of course, whatever antenna you use it should be as high and as in the clear and outside as possible. Having said that my QFH is pushed up through the branches of a tree. I also use an old 2 metre pre-amplifier to give the signal an added boost.


Monday, 22 December 2014

2014 goals update


Earlier this year I wrote about my thirty years as a radio amateur. I created a to do list, here's how I got on:
  • Have a JT65B QSO - I have completed quite a few contacts on 10W, mainly on 17m, it is amazing how far low power can reach as I have made contacts from Japan to South America.
  • Run WSPR to test antenna configurations - I have used WSPR to check out antennas as I have made changes.
  • Receive QRSS signals - Done, see here
  • Amend my Arduino WSPR system to also transmit QRSS. I've done this, and also added transmission of Sequential Multi-tone Hellschreiber, see here
  • Build a 70Mhz amplifier - I completed my 70Mhz transverter by adding a 10W amplifier made by an amateuamateur in Poland. It now drives a Philips A200 linear to 50W.
  • Erect a 50/70Mhz beam - I built a 4m Moxon but still want to get something better up.
  • Have a go at meteor scatter operation on 50/70Mhz - not achieved, the 4/6m beam is a prerequisite.
  • Receive signals bounced off the moon. Not achieved, I'm going to take it off the list.
  • Do some portable HF operating with my FT-817. Not really achieved, apart from one contact while on holiday.
  • Get my CW speed back up to something usable - I think this is a long shot but it needs to be on the list! It's improving but still a little way to go.

Mini-Digi-Holiday-DXpedition

This year I decided to try some operating from our holiday location of Saas Fee in Switzerland (JN36xc, or so the app on my phone told me). I decided to only use WSPR and JT65 on the 40/20/17m bands. These are the bands that I have made loading coils for use with my PAC-12 vertical antenna.

20m WSPR

17m WSPR

Digital only because 5W from an FT817 doesn't go very far when surrounded by 4000m peaks on three sides as Saas Fee is.

It took me a while to make my first JT65 contact (on 17m) because at times the QRM on 20m was very high, with some specific QRM on the 17m JT65 frequency. I didn't track down the cause of the interference but I assume it was something in the village. When it was not present I received signals from Japan to south America as you can see from the PSKreporter screen shot below.

20m JT65 signals received in 30 minutes


20m JT9 received in the US
I was pleased to see that my JT9 signal was received in the US.


 40m WSPR reception was good around Europe.

My 40m WSPR signal was received in VK.

Despite calling CQ on JT65 and JT9 I only managed to make one JT65 contact, this seems odd to me given the fact that I could see that my signal was being logged on PSKReporter. I am happy that my antenna was working well based on its performance with WSPR.

Given the efficiency of JT65 I had assumed that it would be possible to make more contacts but I can only surmise that the reason I didn't was because of the following:
  • 2.5W is too low power
  • Other stations got confused by the different message format that JT65 generates when using a callsign prefix.
Given that the take off was shielded on three sides by 4000m mountains I am pleased with the receive performance of the PAC-12 antenna.

On one day I took the 817 out of the apartment and tried for some SSB contacts on 40m. The beauty of the location I was at is that at 2397m it was about 600m higher than Saas Fee and with a clearer take-off to the north. The noise figures on 40m here was S0 and there were many special event stations loud and clear. Unfortunately, they were generating pile-ups that I was not going to break through with 5W. I did have one contact into north Wales but it was hard going for the other station.

I would like to get my CW skills polished up so I can try some QRP CW for holiday operating, next year we are going on holiday to somewhere with a better take-off which might also help.