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.

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.

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

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

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

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.

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.

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?).

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?

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.

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

So first things first, Hobbies are Hobbies.

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

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??

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.

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

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

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

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?

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.

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.

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

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

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.

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.

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?

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.

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.  

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.

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.

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

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

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?

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.

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

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

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.

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?

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

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

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?!

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.

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

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.

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.

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

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.

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

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.

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

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!

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

Thanks man, great project so far :)

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

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.

It's good now THANK YOU :D

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.

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? 

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.

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

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.

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?

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.

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.

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.

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.

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.

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!

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.

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.

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.

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

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

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.

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.

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.

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.