Close
0%
0%

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

joeJoe
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: https://www.sparkfun.com/products/13910

  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 (http://www.50dollarsat.info/)
  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.

Communicator_Code_BETA_v2.zip

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

Download

PacketStreamDemo.zip

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

Download

RFM69_old.zip

Use in place of RFM69 library with Communicator_Code_BETA_v1

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

Download

Communicator_Code_BETA_v1.zip

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

Download

communicator_v2p2.sch

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

Download

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.

    Summary:

    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: https://cdn.hackaday.io/files/19700842844800/PacketStreamDemo.zip

  • 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.

    https://cdn.hackaday.io/files/19700842844800/Communicator_Code_BETA_v1.zip

  • 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: https://www.adafruit.com/products/1317

    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: https://cdn.hackaday.io/files/19700842844800/Unit Tests.zip

    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 trekcore.com: http://trekcore.com/audio/
    2. I brought it into Audacity (http://audacity.sourceforge.net/) 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: http://sox.sourceforge.net/
    6. Finally, I used wav2C to create a program memory constant of the wav file: https://github.com/olleolleolle/wav2c
    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?

Share

Discussions

josephchrzempiec wrote 01/12/2024 at 04:30 point

Hello, I know it been a couple years sense I saw this project. But I was wondering If it's dead in the water or is it working? I love this project but been having to many health problems and Now I'm back.  To see about this project again.

  Are you sure? yes | no

TheotherMike wrote 01/12/2024 at 17:43 point

Hi, I´m also still interested in this project. At that time, I tried several weeks with different libraries, but was not able to get it working correctly. Had to admit, that I do not have enough grey matter/programming skills to solve it.

  Are you sure? yes | no

Ajb2k3 wrote 08/19/2021 at 05:20 point

Has anyone heard from Joe as there has been no sign of updates.

  Are you sure? yes | no

josephchrzempiec wrote 11/12/2021 at 06:29 point

I wish there was another version of this with something other then a Teensy.

  Are you sure? yes | no

Barney Morrison wrote 01/28/2019 at 23:17 point

Is this project still alive? I'd love to see it working and build my own one's some day. Thank you for sharing!

  Are you sure? yes | no

josephchrzempiec wrote 09/05/2018 at 07:25 point

Hey Joe how is the comm Badge coming a long? It has been a while sense i have been online and wanted to keep in touch.

  Are you sure? yes | no

ma wrote 04/06/2018 at 13:01 point

Where would you put this project in terms of "working devices can be made using the instructions currently posted"? I'm going to a few Cons later this year and would love a device like this to use.

  Are you sure? yes | no

TheotherMike wrote 04/06/2018 at 16:18 point

I just can speak for myself, but I was able to rebuild the hardware. Assembly and soldering worked immediately. Using the provided test sketches I was also able to test speaker, tap-detector etc. It all worked on its own, but in the end I was not able to transmit voice using the transmitter sketch. I do not know what´s the reason for that. I think there´s some error in my compilation/Arduino IDE ??? 

I´m still wondering how to get it running. Some weeks ago I asked Joe again, but he seems to be very busy...

Neo (also made some comments here) made a version using an ATSAM-µC, but information is very sparse.

After all, the device is very cool and very, very compact and I still want to get it running, but at least for me there´s something wrong regarding the transmitter sketch (library?).

  Are you sure? yes | no

TheotherMike wrote 05/27/2017 at 09:59 point

Uploaded node 1&2 to both devices ...unfortunately no transmission possible. Both chirp when tapped and serial puts out "transmission started"... ??

Having one device connected with the pc by usb I can trigger the following output wireless:

[1] Cypher: q   [RX_RSSI:-48] - ACK sent, start stream RX
Start Stream RX
start Sleep
[1] Cypher: …   [RX_RSSI:-39] - ACK sent, start stream RX
Start Stream RX
start Sleep

So rfm´s seem to work, but no sound...

Do you have any ideas I could check?

  Are you sure? yes | no

Joe wrote 06/19/2017 at 04:34 point

Sorry for the delay, I haven't had any free weekends in a while. The issue is the RF module and not streaming reliably. I have made a major breakthrough this weekend and will have a much more reliable version that uses packet streaming instead of bit streaming. Hopefully I will be able to post the source code soon.

  Are you sure? yes | no

TheotherMike wrote 06/19/2017 at 11:08 point

No worries! Life´s never boring. :-)

So first things first, Hobbies are Hobbies.

  Are you sure? yes | no

TheotherMike wrote 05/07/2017 at 17:05 point

Tadaaa, Juhuu.....first device assembled and working! :-) Had some minor selfmade issues , but Joe´s design is nice and first tests of accelerometer, microphone, speaker are working.

Will assemble a second device within the next days or so for testing transmission...

https://hackaday.io/page/3168-joes-star-trek-communicator

  Are you sure? yes | no

TheotherMike wrote 05/07/2017 at 19:53 point

Just played around with it a little bit more...now I´m not sure if the audio amplifier is working correct. The chirp is relatively quite, so I took some talkie examples and they are nearly not audible. 

Just for testing, I set PA_EN=0...after opening the serial the device seems to function normally, of course without sound, but it does not reboot and its output is continuous...might be a power issue??

  Are you sure? yes | no

Joe wrote 05/08/2017 at 00:51 point

Congrats Mike, I think a power issue is a very smart place to start looking. Are you bypassing the battery charger? In my demos I was taking the USB power and connecting it directly to the input of the regulator through a jumper wire. Another thing to check is current consumption. My default code was consuming around 40mA@5V with the PA on on my board.

  Are you sure? yes | no

TheotherMike wrote 05/08/2017 at 08:55 point

Thank you Joe, I will try and check consumption asap. Looks plausible at first sight, indeed I tested it without Bypass and without LiPo...

  Are you sure? yes | no

TheotherMike wrote 05/08/2017 at 19:19 point

Alright, it works fine now! Attached a small LiPo on the backside and now its much better. Charging is also working. In future I think one should limit the charging current a little bit more (5-10 kOhm) because the small LiPo is charged in super-fast 3C mode at the moment...not that ideal.

Using the continuous chirp and the Talkie lib as well it was already a lot of fun letting it say "Danger, Danger,..." :-))

Can´t wait to find some hours for next assembly and testing your full code...!

  Are you sure? yes | no

TheotherMike wrote 05/26/2017 at 10:33 point

2nd Tadaa, second device finished. The first item had some difficulties because my hotplate is magnetic and some parts were kicked off at soldering start. I decided to put a peace of aluminum onto my hotplate in order to gain some (lateral) distance to the magnet in it. It took about 1.5 Minutes longer than without the aluminum piece but everything worked fine on the first try (no tombstoning for today! ;-))). Still need to get a second LiPo, the speaker and the RFM are a little bit power hungry. Perhaps I´ll try the already mentioned bypass cable...we´ll see.

I´m curious how it will behave...

https://hackaday.io/page/3316-joes-star-trek-communicator-second-device

  Are you sure? yes | no

Neo wrote 04/06/2017 at 20:41 point

I got the new version working. I am however getting some strange behaviour. The audio I'm getting through sounds veeery robotic and quite noisy. I've set one end to transmit a sinewave for testing and I'm getting this on the scope http://imgur.com/a/CNjhw (yellow is sender outputting on the DAC what's being sent, and red is what comes out of the receiver's DAC). I'm guessing the pauses in the sender is just the SPI transactions going out, but why is the receiver getting so out of phase? The different waveforms happen when I turn it off and on, it seems to be 'catching' it the right way sometimes, but others it's just all wrong. 
Any ideas?

  Are you sure? yes | no

Joe wrote 04/14/2017 at 04:34 point

Sorry for the delay, here's a couple thoughts:

1) Skip the DACs and send the data through the serial console. The new version of Arduino has a serial plotter mode so you can see the waveforms on your PC with no noise/quantization effects, etc.

2) Does the wave change over time. i.e. leave it running and see if the data eventually transitions from the first screenshot to the second etc. If it does, the link is dropping bits which can cause behavior like this. The red lines look like they have some bit offset (the first N bits were missed so the RX realigns to a sub-MSB) (PM me if you want a better explanation of this through hangouts or skype).

When you turn it off and then back on do you turn both receiver and transmitter off/on? In streaming mode there is no good way to ensure bitstream synchronization unless both transmitter and receiver start at a known point. This can be done by following this procedure:

1) Both RX/TX off

2) turn RX on (it will wait for RX synchronization frame before continuing the stream)

3) turn on TX to start stream

This is the only way to ensure synchronization.

  Are you sure? yes | no

Neo wrote 04/14/2017 at 20:36 point

1) I have it working at the same rates as your sketch but with RadioHead and a different approach, so I think the DAC can handle the speed. But I will test these days with the serial and see if it's the same, good idea.
2) it does snap around after a while, sometimes ok sometimes to another corrupted version. I understand what you're saying and it makes sense.
3) turning the sender off and on makes it work just fine the first send, then second send etc gets corrupted. the receiver can just be on the whole time.

I get what's happening now, I'll check my antennas and stuff maybe I have a poor connection.

  Are you sure? yes | no

TheotherMike wrote 04/04/2017 at 08:32 point

Hi, did you made some range estimation?

[I´m still not able to start assembly...all items arrived but bootloader Chips still have not...hopefully within the next week.]

  Are you sure? yes | no

Joe wrote 04/06/2017 at 02:23 point

No range estimations yet. I have to working from the opposite end of my house. That's all so far.

  Are you sure? yes | no

Neo wrote 04/02/2017 at 09:08 point

Hey Joe, I'm curious, what's the audio quality like for the finished board? I got my SAMD21 version working and it sounds pretty much like a 2$ kid's toy walkie talkie. I'm not sure if it's the audio amp I'm using (a pam8403), the mess of wires I have, or the software.

  Are you sure? yes | no

Joe wrote 04/04/2017 at 02:39 point

Hi Neo, It is 8-bit audio, but it shouldn't be too bad... You can compare the audio quality by recording something in Audacity and converting it to 8-bit, 16k-samples/second. 

Here's an example of 8-bit 11k-samples/second, it sounds pretty good for speech: http://www2.engr.arizona.edu/~429rns/audiofiles/howsoon.wav 

I suspect you have an audio amp/mic issue. If it sounds bad, I would check if your micro's audio DAC is really a DAC or just a PWM, which would need a low-pass filter.

  Are you sure? yes | no

Neo wrote 04/04/2017 at 09:56 point

Does the library stop the interrupt (and thus ADC sampling) every time it transmits something over SPI? or is it fast enough that you don't miss any samples?

  Are you sure? yes | no

Joe wrote 04/06/2017 at 02:22 point

Once the transmission is stopped, it can't easily be restarted because it would need to send a new sync frame. Therefore the timer interrupt must be perfectly timed with the transmission bitrate, which is what I do in my example.

  Are you sure? yes | no

josephchrzempiec wrote 03/23/2017 at 17:38 point

Hello Joe congrats on the Smooth Transmitting part. I mange to get my Arduino transmitting and receiving.  Working on  adding the Tap detection part. Then I'm going to work on the Sound part. My self right now i wanted to test see if i want mange to do some tapping and lighting up some Led's, Then move onto the Sound.  

  Are you sure? yes | no

[deleted]

[this comment has been deleted]

TheotherMike wrote 03/10/2017 at 07:57 point

Intervaltimer is a Teensy specific function. Did you compile it using the "Teensy LC" board in the IDE? "Intervaltimer" does not work with common Arduino boards.

Did you check the RFM lib using an Editor? There must be  the Streaming class inside. As already mentioned below, it compiles well with Arduino 1.8.1 and Teensyduinoinstaller 1.35.

  Are you sure? yes | no

Neo wrote 03/10/2017 at 20:02 point

Hey joseph, the only thing that would not work on a SAMD21 board, which is what I understand you have, is the timer part. You can try the following sketch to see how a timer can be set on a SAMD21 processor in Arduino. I found it in an instructable on DACs or something, don't remember exactly. The code in the link should just blink pin13 on and off, but you can set it to 15kHz or whatever the communicator sketch uses and call the respective functions. I don't have a proper working example because my Feather M0 code doesn't seem to work yet  with the RFM69 (haven't had time to figure out why). Maybe you'll have better luck

LINK: https://gist.github.com/nonsintetic/ad13e70f164801325f5f552f84306d6f

PS: make sure you use the library 'RFM69_Stream.zip' in this project's file section. the one in the examples joe posted is an old version that doesn't have the receiveStreamByte functions etc.

  Are you sure? yes | no

Jonathan Beri wrote 03/09/2017 at 02:50 point

Have you looked at any of the 802.15.4g-based devices? I think they might meet all your requirements. TI is known to have have one of the lowest-powered parts, plus they have the MCU embedded on the device, so no need for extra micro . I'd take a look at the cc120xx and cc13xx, though all the other folks doing RFICs have 802.15.4g options.

(Disclaimer I don't work for any silicon vendor nor do I have an axe to grind. Just familiar with the low power wireless space.)

  Are you sure? yes | no

Joe wrote 03/11/2017 at 17:39 point

Yes, I remember looking at the CC series from TI several years ago. From what I remember, the ADC/DAC were either missing or couldn't support the requirements  of the system (data rate, precision, etc.). Actually I don't think it has a DAC at all. More importantly, I wanted a micro that had a lot of community support. I didn't want to waste time writing timer libraries etc. 

But I agree, with more effort, I think it would be possible

  Are you sure? yes | no

Jonathan Beri wrote 03/15/2017 at 18:14 point

cc actually covers their entire Wireless MCU line - bluetooth, Wi-Fi, 802.15.4, etc. What are you using the DAC for? Audio? Is I2S sufficient?

  Are you sure? yes | no

Joe wrote 03/15/2017 at 19:08 point

Yes, the DAC would be for audio. I2S would still ultimately require an I2S audio dac/driver/amplifier. plus it is probably a bit overkill for low bandwidth, 8-bit audio. I think the simple solution would be to use one of the timers in PWM mode with a low pass filter. Again, I just don't want to have to write the library for it. Teensy has a PWM-DAC library ready to use.

  Are you sure? yes | no

Jonathan Beri wrote 03/15/2017 at 19:37 point

heh, you're probably right. So no nyan cat egg easter egg @ lossless audio?

  Are you sure? yes | no

Neo wrote 03/07/2017 at 18:15 point

Joe, are you sure the uploaded example sketches for the transmitter and receiver are correct? The ones in Communicator_Demo.zip I mean.

Far as I can tell the idea for the transmitter is that you have an interrupt that runs at 15.626kHz that gets one sample (8 bits) from the ADC and sends it to the RFM69 via sendStreamByte() and that should get stored in the FIFO on the RF module. Then every 200ms you tell the radio to send the data out.

But in the example in Files I don't get why you need the 'sendbuffer' variable at all, since you're just pushing stuff straight over SPI to FIFO. Shouldn't the interrupt add bytes to the 'sendbuffer' instead? Could you please check if the code works, or maybe upload the code you used in the video (guessing it's evolved a bit since the first upload :D).

Thanks!

PS: this is what I'm getting on the scope for the transmitter http://imgur.com/a/yhAAL (red is the DAC pin, yellow is the IRQ line), seems like there's large pauses (that 200ms delay in the sketch) where nothing happens, just doesn't seem right (I may be wrong, still learning all this).

  Are you sure? yes | no

Joe wrote 03/07/2017 at 21:03 point

Hi Neo, This is a primitive version of the code I used in the video... Because there is no handshaking happening, you need to turn on the receiver before the transmitter to make sure it is ready. There is an important reason for the buffer. The buffer is used to fill the FIFO at the beginning of the transmission. The streaming happens at a constant bit rate. Because of this constant bit rate, the FIFO is constantly being emptied at a rate approximately equal to 15.626kHz. Therefore, we need to fill it at the same rate to make sure it doesn't empty. Once it empties, the transmission is ended. So we fill it at the begining to lessen the chances of it running out.

What I would try: unplug both chips. Plug in the RX, wait 2 seconds, plug in the TX. Hopefully that will work.

  Are you sure? yes | no

Neo wrote 03/07/2017 at 23:23 point

So.. basically sendStreamByte() loads a byte into the FIFO, receiveStreamByte() gets one byte from FIFO and the radio.stream() in the loop of Tx restarts the transmission if it's stopped for some reason. Right?

So the stuff I'm seeing on my scope is the transmission starting then stopping after a while and then getting restarted 200ms later when the loop kicks in. So that means I'm not filling the FIFO fast enough?

  Are you sure? yes | no

Joe wrote 03/11/2017 at 17:46 point

If the transmit timer and receive timer are running at the same rate it is unlikely that the FIFO would empty. I have found it much easier to debug with serial.print statements. I start by printing the each byte I send to the radio. Them on the receiving end I print the data received. In the past I sent an incrementing variable to make sure the data was not getting corrupted. It was getting corrupted because I was using the teensys regulator which was not strong enough to power the radio. So DVD is another thing to check

  Are you sure? yes | no

Joe wrote 03/13/2017 at 02:06 point

Hi Neo, I just uploaded the demo code again after testing it with my setup. I also added the code used in the actual demo video. Here's one important thing to check. The default radio frequency was 433MHz, you are probably using the 915MHz version. Therefore, make sure you have the right radio version selected, i.e.

//#define FREQUENCY   RF69_433MHZ
#define FREQUENCY     RF69_915MHZ

  Are you sure? yes | no

TheotherMike wrote 03/06/2017 at 18:20 point

Neo, how did you make it work? I´m still having trouble :

(Transmitter:75: error: 'class RFM69' has no member named 'streamingMode'

   radio.streamingMode();)

I downloaded the lib and copied it several times now into the library folder....I also searched for "radio.streamingMode()" within the lib files, but there´s nothing?!

  Are you sure? yes | no

Joe wrote 03/06/2017 at 19:12 point

Hi Mike, here's my experience... Fist, make sure you see radio.streamingMode() in the files you downloaded before copying them over. Maybe there is a weird browser caching issue. Next, I have found older versions of the Arduino IDE store libraries in different places. Therefore, on my machine, I have found several copies in different places. I would check the compile log to see which folder it is getting the library from.

  Are you sure? yes | no

TheotherMike wrote 03/06/2017 at 20:05 point

Oh my God... I never thought that could be possible...!! I used my girlfriends machine, downloaded the file again, et voila a different content. After copying it using a usb drive it compiles now without a problem !! Awesome, thank you for your good advice! Btw, today my OSH-boards came in and so I´m only missing the LIS3DHTR and the MKL02...

  Are you sure? yes | no

josephchrzempiec wrote 03/07/2017 at 07:26 point

Joe what version of arduino IDE did you use and Which library did you use? Reason I'm asking is because I'm also having a hard time with the library you provided.

  Are you sure? yes | no

Neo wrote 03/07/2017 at 10:20 point

josephchrzempiec, make sure you download the library again from the files section, it's been changed (file name is the same). if you have the right version you should be able to find 'streamingMode' in the RFM69.cpp file.

  Are you sure? yes | no

Joe wrote 03/07/2017 at 14:45 point

I used the newest Arduino, 1.8.1 I believe. And most importantly the newest teensyduino

  Are you sure? yes | no

TheotherMike wrote 03/07/2017 at 07:48 point

josephchrzempiec, you can get it compiled using the latest Arduino IDE (1.8.1) and the latest Teensyduino installer 1.35. First, install Arduino, second Teensyduino. You have to Switch the board type to Teensy LC afterwards in the Arduino IDE.

Using a "Standard" Arduino board you might get an error concerning the Intervaltimer. I think Neo has modified it for use with the ATSAMD21 (Arduino zero), but I do not know how he did it in detail. The libraries above are indeed working, just make sure (with an Editor you can search within the "RFM69.h etc) you find "stream" somewhere in it.

  Are you sure? yes | no

Neo wrote 03/07/2017 at 10:23 point

I'm still working on my samd21 version, not sure if it's working yet. On anything that isn't a Teensy, you have to change the timer code to something that works (different implementations for each platform sadly, no unified library). I'll make a project when I do get it working (full credit to joe of course).

  Are you sure? yes | no

Neo wrote 03/04/2017 at 09:53 point

Hello, I'm trying to replicate your project (with a SAMD21) but I think the RFM69 library you provided in the send/receive example isn't the right one. I'm getting compile errors for radio.streamingMode() and radio.sendStreamByte(data). I can't seem to find that code for those anywhere.

  Are you sure? yes | no

josephchrzempiec wrote 03/04/2017 at 17:00 point

hello I myself tried it on a uno and mega board and worked. But not on the teensy or arduino m0 board.

  Are you sure? yes | no

TheotherMike wrote 03/05/2017 at 11:26 point

Indeed, I have the same difficulties with the radio.streamingMode()...!!  Might be that´s what Joe means with the "custom library trunk" because the original lib does not support continuous mode?!? Im using Arduino 1.8.1 and the latest teensyduinoinstaller for now. How did you managed to solve the "Intervaltimer" for the samd21? Isn´t this timer a teensy function?

Would be great to get it running on several systems!

  Are you sure? yes | no

Joe wrote 03/05/2017 at 17:42 point

yes that is a custom function that I wrote. I must have forgot to post the new lib. I'll do that later today.

  Are you sure? yes | no

Neo wrote 03/05/2017 at 19:13 point

Thanks man, great project so far :)

  Are you sure? yes | no

Neo wrote 03/06/2017 at 08:12 point

The library you added yesterday (RFM69_Stream) is still missing those extra functions :(

  Are you sure? yes | no

Joe wrote 03/06/2017 at 16:49 point

Really! I wonder where I copied that from. I didn't think I still had the original version... Anyway, I have now replaced it with the correct version.

  Are you sure? yes | no

Neo wrote 03/06/2017 at 16:59 point

It's good now THANK YOU :D

  Are you sure? yes | no

josephchrzempiec wrote 03/04/2017 at 03:11 point

I have got my wireless modules in, as well as the microphone and speaker 3 days ago but haven't got around to tested it into today. So today I have tested a hello word test and it did work at 1/4mile with no problem. This is awesome sense I do not have the speaker amp yet.u couldn't get the speaker or microphone hooked up. But as I was getting home nail came in and it was the audio amp and 3 axes gyro with it. So tomorrow going to test the microphone on my meter and see what I get from it as well I will test the speaker and audio amp as well. I will post a update layer on.

So far everything is awesome.

  Are you sure? yes | no

TheotherMike wrote 03/04/2017 at 16:06 point

Hey that´s wonderful! I´m also interested what parts (breakout boards?) you use and how you have tested it / setted it up and running? 

  Are you sure? yes | no

josephchrzempiec wrote 03/04/2017 at 18:32 point

Right now at this point i solders male header pins onto the rf modules to make it breadboard friendly. I had to bend some header pins over a little to make it fit. But it was better then soldering one wire at a time and making it fit and look crazy. LOL then i used the library. Then i went to https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/rfm69-test to try it out. I didn't get no where with it. So i searched online for a library and example. I can't find it now because I'm on the road when i get back home in 2 days or close to home then i will update this post with that link in it.

  Are you sure? yes | no

Neo wrote 03/01/2017 at 09:20 point

Glad you got it working, looking forward to the RF part of the project, what library did you think of using for the RFM69 ?

  Are you sure? yes | no

Joe wrote 03/01/2017 at 16:47 point

I am using a custom trunk of the https://github.com/LowPowerLab/RFM69 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.

  Are you sure? yes | no

josephchrzempiec wrote 03/01/2017 at 21:52 point

Hello Joe so i have a question. So if one of the nodes if clicked that becomes the master and all of the other ones are slaves and listen, And once done it releasing being a master then any other node can click and become a master then the rest will be slaves into that second use releases it and hen someone else can be master so forth?

  Are you sure? yes | no

Joe wrote 03/01/2017 at 23:14 point

josephchrzempiec, that handshake methodology is correct. The chalenge is knowing when the master is done... I am hoping to use the audio level with a timer but it might prove to be dificult. I might have to have the master tap to end the transmission.

  Are you sure? yes | no

josephchrzempiec wrote 03/01/2017 at 23:27 point

Hello Joe i would also do that. Because if you remember in Star trek no matter what version of the TV show they did was tap to connect the call and tap again to disconnect the call.

Or tap once to talk for a few seconds and say Joseph to Joe then it will disconnect and the other side they can say tap once will active a timer and say Go for Joe. Then back to Joseph taps twice to connect the call and he can tell his thing and talk when he is done talking tap twice and Joe then can tap twice and talk into he is done then tap twice to disconnect the call.

  Are you sure? yes | no

TheotherMike wrote 03/02/2017 at 18:44 point

When thinking about usability, it´s absolutely necessary to have a timeout after a tap (lets say 2 minutes or so). I know several cases where a walkie-talkie (pmr) was permanently ransmitting because of a jammed transmit button. The sender did not know that and all others had no chance to tell him, leading to hours of random noise on the receiving sides. Tap to speak and tap again to stop is good, but not enough. Perhaps, depending on noise floor level, one could use a time averaged audio volume level as a threshold. For this, it might be useful to continuously sample the noise floor even when not in transmission mode. Perhaps, this might also be a way to automatically scale the output speaker volume...?? So, shortly before a tap, the background noise would be known and the timeout threshold could be calculated. And on the receiving side, the output volume could be calculated based on the local noisefloor around the receiver.......Of course, this only works in cases where the backround noise does not increase massively while speaking.  In addition, the end of a transmission should ideally be terminated with a very short beep to give feedback the transmission is definitely over. Then, in case the background has increased and no stop-Beep was audible, tap again.

In summary:

-Limit transmission time to an absolute maximum (2 min, 3 min,...) to eliminate the risk of jammed channels.

- Continuous audio sampling to sense background noise for calculating threshold for transmission end detection as well as scaling the volume out.

- Beep when transmission ends.

- Override everything and stop transmission with a second tap.

...well, just my 2 cents.... would be nice to have, but the above sounds easier than it is. Myself, I´m just a beginner in terms of programming and electronics. So I highly appreciate the work already shared here and salute to joe and his fast progress.

  Are you sure? yes | no

josephchrzempiec wrote 03/03/2017 at 15:38 point

Hello TheOtherMike. You are right it's just  few things i saw while watching Tv that's all. But this project can be many things. Jow has made a awesome project thank you for that Joe.

  Are you sure? yes | no

josephchrzempiec wrote 03/03/2017 at 03:05 point

Hello TheotherMike Thank you for that information. Yes a max of a 2 minute talk will be the max. But  i think a 2 stage of talk would be great. First if tap once timer will start that will be 10 to 15 seconds timer. That way you can make a contact between you are that person. It is what i saw while watching Star trek over the years then after that time out is finished it disconnects that call.  And that person responds back. a timer is set to 10 or 15 seconds. When that timer is finished then that person can tap again and that 10 to 15 seconds starts again and have a short talk. Or tape twice and a 2 minute max timer starts and have a longer talk. But what happens if need a longer then two minute talk. Well then at that time maybe can add a third stage. While can be up to say 10 to 20 minutes. I think that would be a useful thing to have. With this project It is limitless. Whatever a person mind can come up with for this project.
But i fell in love with this project. Because one it is from start trek and two is the communication badge.

  Are you sure? yes | no

TheotherMike wrote 03/03/2017 at 10:40 point

I don´t know if that´s practical...within your case, there´s a deadtime of 20-30s no one can speak. A fixed timer only leads to massive delays...and every user is impatient! ;-) In some cases even 2 seconds are too Long.   Additionally, it does not need to be fully comparable to the original one in the movies because there are sometimes some Logical Errors in the series ! ;-) . Just using it as a "simple walkie-talkie" (with a continuous-transmission-prevention-override) would be very comfortable, fast, usable, safe, fun&easy....and would be much better than anything already made.

But he has shared everything up to now, so you can adapt it to your demands... That´s cool, and I love it too!

  Are you sure? yes | no

josephchrzempiec wrote 03/01/2017 at 05:56 point

I'm still trying to figure out how to program it on a arduino board. Sense I do not have a Teensy board, And i do not know how to program one. The board i have is a Arduino m0 pro which uses the same chip set as the Teensy chip you have here.

Any chances who might be able to help out on the code side with this? Sense my background is hardware. And i know a little programming But not by much.

  Are you sure? yes | no

Joe wrote 03/01/2017 at 06:21 point

If it is the exact same chip then you can just program it with no changes. You will need the teensy libraries to compile it though. That's a matter of downloading the LATEST Arduino IDE. Then downloading the Teensy software that installs on top of it. In the IDE I think you can just set the board to be 'Arduino m0 pro' and click upload program.

  Are you sure? yes | no

Neo wrote 03/01/2017 at 09:17 point

The Arduino M0 Pro uses a ATSAMD21G18 processor, it's a different chip with different peripherals, so it won't work with some Teensy libraries. Teensy is based on a MK20DX processor. They are both ARM Cortex, but the peripherals and stuff aren't the same. You may have to rewrite some stuff to get it to work the same.

  Are you sure? yes | no

josephchrzempiec wrote 03/01/2017 at 15:03 point

Hello Neo you are correct i looked at it more carefully.   

  Are you sure? yes | no

Joe wrote 03/01/2017 at 16:49 point

Most of the code is chip-independent for the most part. I am using internal pulllups on the I2C bus which requires the Teensy I2C library. That will likely have to be modified. Only the tap detector uses I2C

  Are you sure? yes | no

josephchrzempiec wrote 03/01/2017 at 04:23 point

A Few of these parts was out of stock from mouser and digikey. But i found them on eBay a little more for just making prototype on breadboard isn't so bad. Like the LIS3DHTR not available on mouser or digikey but found it on eBay in the us between $9 and $11 US dollars.

  Are you sure? yes | no

Joe wrote 03/01/2017 at 05:00 point

I just looked, it looks like mouser has 100k on order now. I wonder if someone came by and wiped them out, it is a super popular part.

  Are you sure? yes | no

josephchrzempiec wrote 03/01/2017 at 05:36 point

I have just a few second ago looked it up again and this is what it told me.

Stock: 0

On Order: 105235 

Factory Lead-Time:
9 Weeks

Manufacturing delays have been reported on this product.

What that means is that there is none :(

i did find this one which has everything on it. For testing this is perfect. What do you think? 

http://www.mouser.com/ProductDetail/SparkFun/SEN-13963/?qs=sGAEpiMZZMs1xdPSgahjwtedbQAIg%2bz3F2/efvvmRug=

And to think about it for building someone this awesome in the long run wouldn't be that bad for paying a little more for a breadboard type of testing board.

  Are you sure? yes | no

Joe wrote 03/01/2017 at 06:17 point

Yes, I was agreeing with you, 100k are on order. This usually hapens when someone buys out the entire stock very fast. It's jsut a bit surprizing.

  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