element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Benefits of Membership
    • Achievement Levels
    • Members Area
    • Personal Blogs
    • Feedback and Support
    • What's New on element14
  • Learn
    Learn
    • Learning Center
    • eBooks
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Dev Tools
    • Manufacturers
    • Raspberry Pi
    • RoadTests & Reviews
    • Avnet Boards Community
    • Product Groups
  • Store
    Store
    • Visit Your Store
    • Choose Another Store
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
Personal Blogs
  • Members
  • More
Personal Blogs
Gough Lui's Blog Jingle Wi-FPy: Encoding a Tune with UDP Packets
  • Blog
  • Documents
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Blog Post Actions
  • Subscribe by email
  • More
  • Cancel
  • Share
  • Subscribe by email
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: Gough Lui
  • Date Created: 29 Nov 2019 9:50 AM Date Created
  • Views 810 views
  • Likes 10 likes
  • Comments 5 comments
  • rsa306
  • wifi
  • hack
  • radio_frequency
  • makevember 2019
  • spectrum analyzer
  • tektronix
  • wi-fi
  • side channel attack
  • makevember
  • holidayspecial19ch
  • raspberry_pi
  • rfradiofrequencych
  • raspberry pi
  • rpi
  • rsa_306
  • wipi
  • model a
  • wipi wifi
  • tektronix_rsa_306
  • radio frequency
  • rsa306_spectrum_analyzer
  • amateur radio
Related
Recommended

Jingle Wi-FPy: Encoding a Tune with UDP Packets

Gough Lui
Gough Lui
29 Nov 2019
image

RF (Radio Frequency)

Enter Your Project for a chance to win a Spectrum Analyzer for the Most Innovative RF Project!

Back to The Project14 homepage image

Project14 Home
Monthly Themes
Monthly Theme Poll

 

I'm not sure, but my last posting on QRSS Data Exfiltration using an NFC interface may not have resonated (haha, get it?) with as many people as I might have wished. Perhaps the nature of CW transmission, Morse Code and NFC are all rather fringe technologies which are not as widely appreciated. As a result, I sought to do something a little more accessible - perhaps something using technology that people would already have at home to do something that almost anyone could appreciate. Continuing on with the theme of "radio abuse" and my tendency to gravitate towards short projects, this time, I use Wi-Fi to send a coded message in the form of Jingle Bells.

 

The Premise

Broadly speaking, Wi-Fi is a technology used to wirelessly network computers and devices together. Most people use this on a daily basis - whether it is the Wi-Fi access point at home communicating to your smart-phone, laptop or TV or using the free Wi-Fi at a shopping centre or cafe. Rarely do people think of it as "radio" however, even though it does use radio frequency spectrum. The more common and older incarnations of Wi-Fi (802.11b, g) focused on 2.4GHz operation, while the less common and newer incarnations (802.11a, n, ac, ax) offer operation in the less congested 5GHz band, and some of the latest (802.11ad) even operate in the 60GHz band. These transmissions are unlike the crude audio-frequency narrow-band transmissions that we commonly associate with radio - an AM signal could be contained within 9-40kHz of bandwidth depending on quality, while most narrow FM transmissions are contained within 16kHz and "wide" FM (broadcast) transmissions are contained within 200kHz. By comparison, the narrowest standard Wi-Fi signal is 20MHz wide (i.e. 100 times wider than a broadcast WFM signal). In the latest 802.11ac Wave 2, 160MHz-wide modes have been introduced as well, all of this taking advantage of the big advances in mixed-signal IC design and software defined radio modulation that has become available in the more recent years. We are less constrained by the limitations of analog circuitry components and their frequency response characteristics.

 

So what has this got to do with Jingle Bells? Well, if you take a standard AM receiver and tune it into a "quiet" part of the band where there are no transmissions, you'll hear a hiss. But if you bring the radio close to some source of electrical noise - you're likely to hear a series of pops, clicks and chirps. Of course, your switchmode supply (or whatever source of interference you chose) is not actually putting out a properly modulated AM signal. It's just putting out blobs of RF energy all over the place. Instead, the radio's internal circuitry reacts to this changing RF, often with changes in signal envelope (i.e. the signal power going from zero up to some level) causing the audio output to be modulated in the same way. This is why, say a 2G GSM phone on a call, has a characteristic "bllrrrrrrrrr" sound when heard in amplifiers and speakers - this is because they are demodulating the signal envelope which changes in line with the TDMA time-slotting of the phone call.

 

So while Wi-Fi transmissions are wide-band in nature, we could use a narrow-band receiver tuned in AM to a frequency within this wide-band transmission and expect it to demodulate the envelope of the signal. Every packet we send should result in a "plop". Send enough packets at the right times and you might even get a "beep" or a tone. String along a few of these, and before you know it, you probably have a tune on your hands.

 

Testing It Out

In order to test out the idea, I decided to use the following equipment and software:

  • Raspberry Pi Model A - since I already had it set-up already from the last experiment.
  • Wi-Pi Dongle - for wireless connection as the Model A doesn't natively have any. You could substitute another Raspberry Pi board with onboard wireless to the same effect.
  • A wireless router/access point - this provides a network to connect to.
  • Icom IC-R20 Communications Receiver - to listen in on the results, although any other receiver capable of narrow-band AM reception in the 2.4GHz range would be suitable including upmarket SDRs.
  • Tektronix RSA306 USB Spectrum Analyzer - Review - optional, but useful to visualise what the program does.
  • Python 2.7 - to run the program that is written. I could have used Python 3, but the example UDP code I borrowed doesn't seem to work with it just yet.

 

In order to send the packets at the timings that I needed, I wrote a short Python program. This program has an array of note frequencies (taken from here) and calculates the note periods. A transpose feature is provided to halve/double the note periods while a tempo feature is provided to adjust playback speed. The notes of the song are coded into an array numerically as indexes, with the duration in terms of beats translated into time on-the-fly.

 

import socket
import time

UDP_IP = "192.168.0.253"
UDP_PORT = 19999
MESSAGE = ">"
notes_hz = [130.81,138.59,146.83,155.56,164.81,174.61,185.0,196.0,207.65,220.0,233.07,246.94]
transpose = 1
notes_period = [1.0/(transpose*x) for x in notes_hz]
tempo = 120.0

# Notes
# C = 0, C# = 1, D = 2, D# = 3, E = 4, F = 5, F# = 6, G = 7, G# = 8, A = 9, A# = 10, B = 11
# Duration
# Qua = 0.5, Crot = 1, Min = 2, etc.

songnotes = [4,4,4,4,4,4,4,7,0,  2,  4,5,5,5,  5,  5,4,4,4,4,4,2,2,4,2,7,4,4,4,4,4,4,4,7,0,  2,  4,5,5,5,5,5,4,4,4,4,7,7,5,2,0]
songdurau = [1,1,2,1,1,2,1,1,1.5,0.5,4,1,1,1.5,0.5,1,1,1,1,1,1,1,1,1,2,2,1,1,2,1,1,2,1,1,1.5,0.5,4,1,1,1,1,1,1,1,1,1,1,1,1,1,4]
songdurat = [x*60/tempo for x in songdurau]

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

i=0
while i < len(songnotes):
    timeend = time.time() + songdurat[i];
    while time.time() < timeend :
        sock.sendto(MESSAGE,(UDP_IP,UDP_PORT))
        time.sleep(notes_period[songnotes[i]]/2)
    i=i+1
    time.sleep(0.1)

 

It's not the ideal code, especially on a multi-tasking operating system such as Linux, as it uses calls to time.sleep() to generate delays, which is necessarily imprecise. Adding to this, inherent delays caused by the CSMA/CA transmission method of Wi-Fi, a rather characteristic "unstable" pitch interrupted by actual network traffic is the likely result. But I'd have to say that this has a charm of its own. To try and reduce the loading on the network to make it more likely that higher notes can be generated, I've decided to send a simple message containing a single angle-bracket. This reduces the air-time consumption to the absolute minimum. As UDP is a connection-less protocol, I just decided to direct the transmission to a computer on the network (so that the hardware Ethernet address would be resolved) which would just discard the packets as part of its normal handling of unsolicited packets. The notes for the song and the durations were transcribed from this piece of sheet music - although i might have made a mistake as this was one of those "I want to try this out before I go to bed" kind of projects.

 

Video Demonstration

Below is a video that overviews the project including the demonstration of the resulting tune on my trusty Icom IC-R20 communications receiver.

You don't have permission to edit metadata of this video.
Edit media
x
image
Upload Preview
image

 

Conclusion

While my aim was to try and do something perhaps a little more accessible, I fear that I might have failed once-more. Perhaps I'm lacking a bit in the Q-department. While many people may have access to a Raspberry Pi and Wi-Fi radio, I forgot that many people may not have a radio that could receive up into the 2.4GHz region in the AM mode to enjoy the resulting tune. Many low-cost SDRs (e.g. the RTL TV Tuner Sticks) only reach into the 1700-1800MHz ranges and even the spectrum analyser on offer in the RF Project 14 only goes up to 1.5GHz. Unless you have a super wide-band receiver, a more upmarket SDR, a down-converter or a higher-end spectrum analyser ... you won't really notice the holiday cheer that this program could bring*. But that being said, this shows us just another means by which data exfiltration and side-channel attacks could occur - even though the network in question is fully encrypted with modern WPA2-AES-CCMP encryption, a rogue node on the network could send packets at a specific timing interval with enough repetitions such that an observer could receive a coded message simply by observing the timing of the encrypted packets. This is actually harnessed by a number of products to do initial Wi-Fi set-up and communicate the encryption key to unprovisioned devices (a number of which are mentioned in this paper). But I guess I could use it to send Morse code as well ... not that anyone would really notice it in passing.

 

* Holiday cheer is not guaranteed. I will not be held responsible should this tune cause any damage or loss of holiday cheer either directly or consequentially. Use at your own risk.

  • Sign in to reply

Top Comments

  • aspork42
    aspork42 over 3 years ago +3
    Shamelessly stole this and ported over to Arduino to test out my new MRK1010 and relay shield. All credit to Gough's work on this one “Imitation is the sincerest form of flattery that mediocrity can pay…
  • aspork42
    aspork42 over 3 years ago +2
    Nice job! I got a good chuckle out of this
  • Gough Lui
    Gough Lui over 3 years ago in reply to aspork42 +2
    Nice work aspork42 ! That definitely gets my approval . Always nicer when you're not multi-tasking/contending with other network traffic ... I remember doing something similar when I reviewed the PiFace…
  • dubbie
    dubbie over 3 years ago

    This reminds me of when microprocessors first came out and trying to make tunes with a speaker connected to an output pin. Ahhh, the good old days.

     

    Dubbie

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Gough Lui
    Gough Lui over 3 years ago in reply to aspork42

    Nice work aspork42! That definitely gets my approval image.

     

    Always nicer when you're not multi-tasking/contending with other network traffic ... I remember doing something similar when I reviewed the PiFace Digital shield in one of my earliest RoadTests, playing the Australian national anthem, although my C-code was perhaps a little less nice back then ...

     

    - Gough

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • aspork42
    aspork42 over 3 years ago

    Shamelessly stole this and ported over to Arduino to test out my new MRK1010 and relay shield.

     

    All credit to Gough's work on this one image

     

         “Imitation is the sincerest form of flattery that mediocrity can pay to greatness.”

              ― Oscar Wilde

     

    You don't have permission to edit metadata of this video.
    Edit media
    x
    image
    Upload Preview
    image

     

     

    void setup() {
      pinMode(1, OUTPUT);
    }
    
    
    void loop() {
      const double notes_hz[12] = {130.81,138.59,146.83,155.56,164.81,174.61,185.0,196.0,207.65,220.0,233.07,246.94};
      double tempo = 120.0;
    /*  
    # Notes  
    # C = 0, C# = 1, D = 2, D# = 3, E = 4, F = 5, F# = 6, G = 7, G# = 8, A = 9, A# = 10, B = 11  
    # Duration  
    # Qua = 0.5, Crot = 1, Min = 2, etc.  
      */
      
      int songnotes[] = {4,4,4, 4,4,4, 4,7,0,  2,  4, 5,5,5,  5,  5,4,4,4,4,4,2,2,4,2,7,4,4,4,4,4,4,4,7,0,  2,  4,5,5,5,5,5,4,4,4,4,7,7,5,2,0};
      
      double songdurau[] = {1,1,2,1,1,2,1,1,1.5,0.5,4,1,1,1.5,0.5,1,1,1,1,1,1,1,1,1,2,2,1,1,2,1,1,2,1,1,1.5,0.5,4,1,1,1,1,1,1,1,1,1,1,1,1,1,4};
      
      double songdurat[sizeof(songdurau)/sizeof(songdurau[0])];
      for(int x=0; x< (sizeof(songdurau)/sizeof(songdurau[0])); x++){
        songdurat[x] = songdurau[x]*60.0/tempo;
      }
      
      for(int i=0; i < (sizeof(songnotes)/sizeof(songnotes[0])); i++){
        unsigned long timeend = millis() + (songdurat[i]*1000);  
        tone(1,notes_hz[songnotes[i]], songdurat[i]*900);
        while(millis() < timeend){
          //wait
        }
      }
      while(1);
    }

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • aspork42
    aspork42 over 3 years ago

    Nice job! I got a good chuckle out of this image

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • dubbie
    dubbie over 3 years ago

    Who would have thought this was possible. A good laugh.

     

    Dubbie

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2023 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • Facebook
  • Twitter
  • linkedin
  • YouTube