Star Trek Communicator Badge

In the true spirit of Star Trek, this communicator badge is completely autonomous, while fitting in the form factor of an original badge

Similar projects worth following
Star Trek was known for dreaming up technology that was deemed nearly impossible given the limitations of the technology for the day. Having a small badge that could send audio across vast distances seemed out of the realm of possibility during the late 1980's. This project's aim is to use modern technology to provide nearly all the features of visionary tech, namely:

- Tap to connect and communicate instantly
- Long range (from orbit to planet surface)
- Small form factor (of an original TNG badge)
- Fully autonomous (no cell phone or base station needed)
- No external power source (i.e. battery powered)

Wireless Transceiver Design Decision Details

A similar project to this could easily be done with a bluetooth audio chipset much like the ones we see in wireless handsfree modules. The problem with those modules is that they don't meet any of the requirements of THIS project. First, they rely on a connection to a cell phone for communication, this would not make the system autonomous. Second, the range of bluetooth audio is very limited, making it impractical to use without being paired to a cell phone.

Therefore, I was tasked with finding a wireless communications system that had:

  1. Small form factor
  2. Low power
  3. Fast enough data-rate to send audio
  4. Long range
  5. Multi-node communications protocol

From this point, I believe I have found this in the RFM69HCW ISM band transceiver. This module meets all the requirements:

  1. Smaller than a US quarter
  2. Low power: Rx = 16 mA, 100nA register retention
  3. FSK Bit rates up to 300 kb/s (fast enough for 8-bit audio with 16kHz bandwidth)
  4. It has been used to communicate from space to ground (
  5. It supports up to unique 255 node IDs

There may be better modules that come available in the future so it is desirable to design a system that can easily scale to use any TX module with minor software and board changes. Therefore, I have decided to base this design on a Teensy micro-controller.

Beta version of communicator code supporting unlimited nodes. streaming library now inherits original lowPowerLab library. Exact RFM69 library now included to avoid version incompatibility.

Zip Archive - 540.23 kB - 11/27/2017 at 00:35


A demo of a packet stream instead of a bit stream. This is way more reliable.

Zip Archive - 575.23 kB - 07/01/2017 at 16:55


Use in place of RFM69 library with Communicator_Code_BETA_v1

Zip Archive - 218.41 kB - 04/04/2017 at 02:20


Beta version of communicator code with two unique nodes. streaming library now inherits original lowPowerLab library.

Zip Archive - 53.08 kB - 03/28/2017 at 00:53



Power switch now controls enable pin of regulator so switch is not in power path.

sch - 292.67 kB - 03/26/2017 at 22:54


View all 19 files

  • 1 × 0915AT43A0026E (915 MHZ antenna) Electronic Components / Misc. Electronic Components
  • 1 × TSX-3225 16.0000MF09Z-AC0 Frequency Control / Crystals
  • 1 × KXT 131 LHS Electronic Components / Tactile Switch
  • 1 × SPU0414HR5H-SB Electronic Components / Misc. Electronic Components
  • 1 × TPA2006D1DRBR Audio ICs / Audio Amplifiers

View all 16 components

  • Encrypted Communications Working

    Joe07/18/2017 at 04:35 0 comments

    I have been thinking about how to encrypt the audio communications with the system limitations:

    1. The RFM encryption method is way too slow and can't support any reasonable data-rate
    2. Therefore, we have to find a method that can work in real time on the microcontroller with a limited number of cycles.

    The solution I have come up with still leverages the RFM69 encryption but only for the initial handshake. Here's how it works:

    1. Master sends encrypted packet to slave using same private key. Packet contains a 30-byte random cypher
    2. If the slave responds with an ACK, we know both the master and slave have the same cypher.
    3. We now switch to non-encrypted mode.
    4. For each 61-byte packet, the data is XORd with the cypher before transmission
    5. The slave then XORs the same cypher after receiving the packet, full reconstructing the data.

    Can this be hacked? Probably. I can envision a hack where you have a good idea of what data to expect (frequency content, mid-scale 0-value, etc.). You might then be able to reconstruct the cypher to get audible data. However, once you have found the cypher (assuming you can find it), the next transmission will have a completely new one. So, I think it's pretty secure for the application.

  • Power Analysis

    Joe07/02/2017 at 21:15 0 comments

    I am looking at bringing the system power down to extend battery life. The power breakdown in idle mode is as follows:

    ComponentActive RX PowerSleep PowerAvg. PowerNotes
    RFM69HCW17mA0.7uA9mA50% sleep duty cycle
    Teensy LC5mA150uA2.5mA50% duty, w/ bootloader
    Microphone155uA155uA155uAAlways on
    LIS3DH11uA11uA11uAAlways on
    Totals22.16mA / 73.1mW317uA / 1mW11.66mA / 38.5mW

    The battery I have chosen has a capacity of 150mAh @ 3.7V. The system runs at 3.3V so energy rating of the batter at 3.3V is 150*(3.7/3.3) = 168mAh @ 3.3V. This means the standby time is 168/11.66 = 14.4 hours. That's a full day of standby time!!!

    I think we can push the sleep duty cycle longer than 50% to save even more power. Probably by as much as 80% duty.

    Now to measure the full system during streaming mode:

    Here, I put the whole system into stream mode and measure the supply current (measured on the battery voltage rail).

    ModePowerMax Duration (based on 150mAh)
    STREAM_RX37mA @ 3.7V4 hours of talk time
    STREAM_TX (31 power setting)39.6mA @ 3.7V3.8 hours of talk time
    STREAM_TX (15 power setting)38.9mA @ 3.7V3.85 hours of talk time
    STREAM_TX (0 power setting)38mA @ 3.7V3.9 hours of talk time

    Wow, 4 hours of talk time! There must be something missing... there is, the speaker. The speaker driver can source as much as 120mA when driving a lout signal. Therefore The talk time is limited to more like 1 hour of receiving.


    12+ hours of standby

    1+ hour of talk time

    Actually, not too far off from an old Nokia bar phone...

  • Packet Stream

    Joe07/01/2017 at 17:21 6 comments

    Finally! A reliable data stream!

    I decided to ditch the efforts I had given into a bit stream (i.e. infinite length packet) and tried to squeeze as much data into a stream of packets.

    The packet system in the RFM69HCW allows for a packet length of 64 bytes, where 3 bytes are overhead. So this is effectively 61 bytes per packet. If I want to transmit at an audio Bandwidth of 8kHz (transmission rate of 16kBps) I need to send a packet about every 62 us.

    This means that I need to send a full 64-byte packet faster than 61bytes * 62us/byte = 3782us (don't forget we need the time to load the packet into the FIFO via SPI). So, if we run the bit-rate of the transmitter at 100kbps that means we transmit 64 Bytes in 640 us. Plenty fast.

    The SPI transactions now need to run as fast as possible to load the fifo in 3782us - 640us = 3142us. We have to transmit at a fast rate for this. This means overloading the base RFM69 class to run at the full SPI clock rate instead of 1/4. So if we can get the SPI running at 5MHz, we can send:

    This leaves us with plenty of time (3ms) to do ADC conversions (which can be slow), read interrupts, etc. So sending 8-bit audio at a reasonable bit-rate is totally achievable.

    In practice I have found that for human voice we can drop the bit rate to 10kBps. This allows us to push some of the deterministic tonal noise out of the human audible range and has no effect on Bandwidth quality.

    Here's a demo for you to try yourself:

  • Beta Code

    Joe03/28/2017 at 00:57 4 comments

    I have an example beta code that runs on two nodes. Each node can start/stop a transmission with all peripherals fully functioning.

    I have changes the RFM69_stream library to inherit the original RFM69 library from LowPowerLab. This way you can download the original library and my library and they can exist in harmony together.

    The files are here. Let me konw what you think so far.

  • Streaming now reliable

    Joe03/22/2017 at 04:21 3 comments

    I managed to get reliable streaming by optimizing the RFM69's settings.I am enabled the Gaussian filter in OOK mode, increased the power level, an improved the end-transmission algorithm. I can reliable start and stop transmissions now. Hooray!

  • Bit Error Rate !!!.!

    Joe03/16/2017 at 04:36 8 comments

    I have started writing the main code for the system. There is a simple state machine (I will probably post the diagram for it later) that manages switching between modes and determining which node is transmitting and when to receive. In short it works like this:

    1. All nodes in standby
    2. When a node wants to transmit audio, it sends a packet (with ECC) to the other node(s).
    3. The other node(s) reply with an ACK
    4. Once an ACK is received the master goes into streaming mode and the slave(s) going into streamingRX mode.

    Everything works great up to this point. Here's where things get funky.

    How do you end a transmission when the entire data pipe is dedicated to transmit audio?

    What I am doing now: when the master wants to end the transmission it sends 1000+ audio bytes of 0xAA. This is a repeating 1010 pattern that allows for good signal integrity. The slave then looks for say, 500 of these packets in a row, to end the transmission.

    Problem: I don't know if this is a "real" issue or not (it could be a bread-board signal integrity issue), but I am often seeing bits be skipped by the receiver (maybe 1 in 100,000 samples or so). For example, if a byte sequence is this:

    10101010 10101010 10101010

    I sometimes get this:

    10101010 10101101 01010101

    Where a bit is dropped causing the byte sequence to permanently be off by 1 bit. This is not only bad for the end-transmission sequence, but also the audio date can get wacky. 1 in 100,000 samples is sometihng like 1 in a couple seconds or so, so it is pretty frequent.

    I fear that the solution may be to double the data rate, or increase it by a couple bits maybe. This would allow for ECC (error correcting codes) or some way to detect a missing bit. Also, maybe Manchester encoding might help.

    My initial thoughts:

    • Make each audio packet 12 bits long
    • first 3 bits are always '111'
    • 8 bits of audio sample
    • 1 bit checksum

    Does anyone have any experience with correcting for missing bits in a bit-stream for this type of application?

  • RF Working, System Working!

    Joe03/06/2017 at 01:09 7 comments

    I am able to talk to the RF module and can send audio data to another device!! See the video below.

  • Battery Sourced

    Joe02/27/2017 at 05:28 0 comments

    I found a battery that just barely fits in the cavity space I have available, maximizing battery capacity. It is a 150mAh battery from Adafruit:

    Just one minor detail though... I forgot to add a power switch on the board. For the first prototype I will have to manually add one in-line with the battery cable. Oops!

  • Unit Tests Complete

    Joe02/27/2017 at 04:30 0 comments

    Every sub-system is working now that the Teensy is up and running. I developed some simple unit tests to help debug the board and soldering.

    The test code can be found here and used to get your own communicator debugged:

    The final step: Get the RF module up and running. First, I will verify the connections with some existing breadboard code. After that, the more major task will be to merge both transmitter and receiver code into the same file.

  • Speaker and Click Sound

    Joe02/27/2017 at 03:29 0 comments

    The Speaker and audio amp is working! I managed to get the TNG click sound to take up only 10kB of memory so I can play it every time a communication is started. Here's the procedure:

    1. I found a TNG click sound at
    2. I brought it into Audacity ( and trimmed the extra dead space at the beginning and end of the file to save memory.
    3. I then optimized the data-rate as low as I could. The click sound is pretty high frequency so I could only get it down to 32ksampels/second before it started sounding poor.
    4. I them exported it as an unsigned 8-bit WAV file
    5. I used Sox to trim extra data from the file:
    6. Finally, I used wav2C to create a program memory constant of the wav file:
    7. I my main code, I dump the audio, sample by sample with a 32kHz timer.

    I'll post the wav file so you can hear what I came up with with only 10kB or program memory space.

View all 16 project logs

  • 1
    Step 1

    Order Parts and PCB: Version 2.1 of the board can be found on (Osh Park). Make sure you check the box for "2 oz copper, 0.8mm thickness." This will get the right impedance for the 50-ohm trace to the antenna. This is a complex build requiring many SMD components. Many components are standard ICs and passives that can be found on this list, but there are a couple components that must be special ordered:

    1. The MKL02Z32 must be purchased with the teensy bootloader pre-burned in it from here
    2. The RFM69HCW must be the 915 MHz version to match the antenna
  • 2
    Step 2

    SMD Solder: This is NOT EASY. The density of this board is very high. The components have very small pin pitches and some CAN ONLY BE REFLOW SOLDERED. For example, the microphone pins are underneath the part have cannot be accessed with a soldering iron and there is a ground plane under the Teensy.

    I recommend building this in steps. Populate the Teensy LC chip, it's bootloader chip, the crystal oscillator, and the reset switch. This will allow you to get the teensy up and running before waisting time with other components. If the teensy doesn't work, nothing will work. You can bypass the 3.3V regulator and use a bench power supply to connect to the 3.3V power pin (and ground of course).

    Test the teensy by connecting to it on your PC and making sure you can program it with some example code or simple blink code. If you can take to it you are good!

  • 3
    Step 3

    Next, or if you don't have a bench power supply, populate the 3.3V regulator and it's associated components. Test it with a multi-meter.

View all 5 instructions

Enjoy this project?



josephchrzempiec wrote 02/22/2017 at 05:18 point

So I'm getting the hang of all your information here  and 2 things in your parts list i didn't understand. there was it looked like two processors  chips. But in fact there is just one chip is the processor and one is a programmer chip. Basically you are just making a all in one board using  a teensy layout and programming correct? Sorry still kinda new to all this.

  Are you sure? yes | no

TheotherMike wrote 02/22/2017 at 07:58 point

Joe is basically building a Teensy LC, with a layout especially designed for use with the RFM69. The basic schematic should be comparable to this one (at least I think so):

That´s also the reason why you Need a Special pre-programmed chip from pjrc. It includes the bootloader program which is needed so you can use the Arduino IDE with the Teensy LC...

  Are you sure? yes | no

josephchrzempiec wrote 02/22/2017 at 08:01 point

Thank you TheotherMike for that.  I had a feeling it was for a teensy board. I my self never had a teensy board. I only learned a lot using arduino and arduino IDE not even sure what is the difference between the Arduino M0 pro board and the Teensy other then it uses the same Processor chip.

  Are you sure? yes | no

josephchrzempiec wrote 02/21/2017 at 21:44 point

Hello i have a question maybe I'm missing this. But which battery are you plan on using with the communicator? Also i was why two processors chips. Is one focus on processing the sound and the other focusing on transmitting and receiving?

  Are you sure? yes | no

Joe wrote 02/21/2017 at 23:46 point

Thats a good question... I don't have one on the list. It must be a LIPO battery as the charger chip is designed for one. Then it's just a matter of size that will fit in the form factor. I haven't sourced one yet but the final design will probably fit about 50-100mAh or so.

  Are you sure? yes | no

josephchrzempiec wrote 02/22/2017 at 01:00 point

Thank you. Being at 50 to 100ma current. How long do you think you might get out of it? What i mean is Do you expect it to last a longer time say over 2 or 3 hours, Or will it last longer? I know these micro processors take low power only a few milliamps But the RF transceiver not sure of.

  Are you sure? yes | no

Joe wrote 02/22/2017 at 01:17 point

the rfm69 has a low power receive mode that only takes 16mA, duty cycled with a standby mode of 1.25mA (and maybe even 0.1uA sleep with clear coding). So the battery life will be dominated by talk time (up to 100mA for max range). If you don't talk hardly at all, I think we can get a full day of standby out of it.

  Are you sure? yes | no

josephchrzempiec wrote 02/23/2017 at 06:55 point

Sense I don't have a Teensy i will look into  Using my arduino i know that the RFM69HCW does work on the Arduino But getting the audio to work will take some Doing. 

  Are you sure? yes | no

Joe wrote 02/23/2017 at 16:11 point

it should work, make sure you choose one with a fast frequency. I think the Uno is too slow.

  Are you sure? yes | no

josephchrzempiec wrote 02/20/2017 at 00:51 point

Hello i have a question in your documentation you are using the M0 chip is that for the arduino m0 pro board chip? The second question i have is what about code for sketch or libraries and what not? I wanted to make one But I'm not a coder my self.

  Are you sure? yes | no

Joe wrote 02/20/2017 at 04:55 point

I am using a Teensy LC chip. This is essentially made up of two arm chips: the main micro (MKL26Z64VFT4) and a bootloader micro (MKL02Z32). The MKL02Z32 chip needs to be bought from with their custom firmware loaded on it. This allows you to them program the main micro via USB with the Arduino IDE. I am far from finishing the software. But I have a demo that puts one module in TX and another in RX. Once I get the new board up and running I will post a better demo SW release.

  Are you sure? yes | no

Neo wrote 02/17/2017 at 18:34 point

Keep up the good work, very exciting project!

  Are you sure? yes | no

TheotherMike wrote 02/16/2017 at 17:55 point

Dear Joe, could you please also update the eagle files?

  Are you sure? yes | no

TheotherMike wrote 02/16/2017 at 17:57 point

...brd ordered... :-)

  Are you sure? yes | no

Joe wrote 02/17/2017 at 07:26 point

Done. When you are ordering parts, make sure you get the MKL02Z32 from PRJC because it needs a pre-loaded teensy bootloader. I'll attach my Mouser invoice so you konw exactly what parts to get...

  Are you sure? yes | no

TheotherMike wrote 02/20/2017 at 19:14 point

Parts now also ordered....your part list was a great help, thank you! The preprogrammed bootloader chips are a bigger problem in Europe and will take some weeks from now on... :-|  Well, it´s getting more and more exciting with your project !! :-)))

  Are you sure? yes | no

josephchrzempiec wrote 02/16/2017 at 07:12 point

Hello 255 nodes is the max what happens if you have more then what is there a way to add more? Also what about code to make the audio to transmit and receive? 

  Are you sure? yes | no

Joe wrote 02/17/2017 at 07:17 point

Actually there is a maximum of 255 node IDs. If two nodes have the same ID it is probably fine. The only reason we would care about the IDs is if we wanted to restrict communications or maybe have multiple channels.

  Are you sure? yes | no

TheotherMike wrote 02/10/2017 at 09:07 point

Perhaps I don´t see it in the Image (no Viewer at Hand...), but don´t you Need pin 2 on GND ?

  Are you sure? yes | no

Joe wrote 02/10/2017 at 17:01 point

Thanks for looking, pin 2 is grounded via a connection to the center pad.

  Are you sure? yes | no

TheotherMike wrote 02/10/2017 at 18:33 point

Alright,, I´m sorry to ask again..... is the center pad really connected to GND. On this computer I have an old eagle version and neither in the .sch nor in .brd I can see a real connection. Might just be an issue with my program or my lacking skills...

  Are you sure? yes | no

Joe wrote 02/10/2017 at 19:03 point

Gosh, I hope I didn't mess that up...The via in the center of the pad should connect the pad to the ground plane below. Where in the sch do you not see the GND connection? I have 3 VSS pins on the left side that are all connected together. Does the image of the schematic I posted look the same as what your eagle is showing?

  Are you sure? yes | no

TheotherMike wrote 02/10/2017 at 19:13 point

Yes, Sir, it looks identical. But I miss pin 2 in the schematic, like shown here:

I´m still not able to verify the gnd-plane...

Edit: I the brd it seems to be all connected...mmhhhh.....

  Are you sure? yes | no

Joe wrote 02/06/2017 at 06:52 point

I am using a custom trunk of the library. I decided that I needed more flexibility to switch between low power packet mode and high-power streaming. Right now, the protocol is designed to send a lower power encrypted packet to tell the slaves to start receiving audio, then I kick the master and slaves into streaming mode. Yes, the LIS3DH is for tap detection. I'll be posting some example fixed master, fixed slave code soon.

  Are you sure? yes | no

oshpark wrote 02/03/2017 at 20:23 point

Exciting project!

  Are you sure? yes | no

TheotherMike wrote 02/03/2017 at 17:17 point

That´s very Cool! :-))

What libs do you use ?  It somehow reminds me of "RF24Audio". But please os firmware!?

The LIS3DHTR is for tap recognition?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates