It works up to 3 feet away, or more depending on encoding. I wondered if anyone would say that. This method also works in a wired fashion.
Re: speed:
Yeah doing DSP in Lua isn’t great. Doing it in C + using C for mic output allows for real-time DSP.
here is my toy frequency detector:
Alright so I am currently making the first ever prototype to test what the Playdate can do in terms of making the first link cable / audio jack co op game.
Only one problem, I am not sure how to check the sample of the sound pitch for audio streaming. Determining the status of both machines.
Currently this is all I have planned right now.
I will be using a audio jack with my audio jack setup with another playdate.
Which will do the following above and then below.
They will ping each other the data
one device will have "ABCD"
send it to P2
and P2 will reply back "ABCD"
P1 will say "TRUE"
or if P2 says "BBCD"
P1 will say "FALSE" "START"
P2 "READY"
P1 "ABCD"
P2 "BBCD"
P1 "FALSE" "START"
etc until it gets it right.
right now both devices haven't been disconnected just having issues communicating.
The START tone is extremely useful for starting over a failed transmission.
I have no experience with C code and currently no progress has been made due to my ability to experiment with detecting any sort of communication.
There is the documentation about getting the pitch and processing it but I have no idea how to code such a thing.
I am more used to coding in Lua.
I do need help having a engine that can fulfill my needs at sending data, processing audio data without performance hiccups.
Hey, you're dangerously close to making the first Playdate guitar tuner!
Love the developments by the way. Excited to see where this goes. I could see making a two-player game which only needs to update periodically and slow updates could work.
pitch and frequency are the same thing and as I pointed out before, here is a high speed pitch / frequency detector:
You can then use this to encode things:
@DJ_irl using my code above you could absolutely make a guitar tuner.
EDIT: also you can def use an audio cross-over cable as well, you just need to force the mic to use cable (it will only work for one side automatically). I haven't done a loopback test. Here is a test demonstrating how fast it can be without using cables:
https://twitter.com/ericlewisplease/status/1706061935836291306
when you use cables the entire setup becomes extremely accurate, essentially meaning you can use lower frequencies too.
Ah, so lovely to have discovered this thread! I've been contemplating this idea of writing a software modem for Playdate too. Namely, one idea to do networking and another to have local "null modem"-style multiplayer.
Perhaps you will find these resources helpful for your work:
Good luck!
After much experimentation, my first prototype using @ericlewis 's pd-frequency-detector as a base is being released. This features a bunch of tools about detecting pitch. I heavily decreased the buffer time and sample rate of the microphone to improve performance.
Few interesting points...
The headset jack MUST be plugged in before starting transmission to another device.
The Mic must say headset in order to transmit information.
Playdate Revision 1 has issues with microphone grabbing especially when getting unplugged. The software will need to be restarted. I wonder how I can reset the mic.
The Hz shown is actually using a 2x math function because I might have screwed up the C code.
pd-frequency-detector-v2 by Vachi.pdx.zip (PDX) (205.5 KB)
pd-frequency-detector-v2-source-vachi.zip (Source Code) (208.9 KB)
CONTROLS
Turns ON Headset Audio mode / OFF Speaker
Turns ON Speaker Audio mode / OFF Headset
Plays a loud sample beep segment. (Volume Warning)
So far I do not have the equipment to test back and forth transmission so I will buy some stuff for it. The device also knows when the microphone doesn't exist on the cable, make sure the jack has THREE segment lines not two.
It took me a long time to get to this point and I am happy I was productive for once.
Have fun experimenting. I will keep reading everyones ideas and issues.
minimodem https://youtu.be/pwuyMJfyNmY
This looks really awesome!
Thank you for showing me this!
I just wonder how accurate it would be on Playdate.
I am not an expert in coding and just only beginning.
I really hope someone or even Panic implements something like this in the future.
You can use the synth to play various notes. That’s how my demos work. Essentially modems are very fast synths. From a high level you could imagine a scheme like this:
A packet frame may look something like:
Play 100hz tone
Play 1000hz tone for 0
Play 2000hz tone for 1
Play 100hz tone
100hz tells your program to engage in “decoding mode” where you know the sample rate and can convert an ~1000hz to a 0, and push it into a table or something. Do this until you receive another 100hz tone and you can transmit a piece of data. If you wanted to transmit a single byte you would play a 100hz tone, 8 1000 or 2000hz tones, then a 100hz tone. On the listening side you simply change states and fill up a table / array. Then you can convert the byte to something else, anything else really.
That basically describes a BFSK. Real modems work in a similar way with more frequencies being used to encode more data in a smaller amount of time.
Creating a BFSK is probably a good first step. But as seen in my demos you can transmit pretty arbitrary information (I did specific buttons per tone for instance).
Edit: also to note the 100hz tone should probably be a higher freq, an interesting artifact of this type of sampling is lower frequencies are less certain with faster sample rates.
Edit 2: you can also push the current frequency to lua instead of pulling it by calling lua from C. There definitely isn’t going to be any modemcode written using the update loop to pull the current frequency since it maxes out at 50fps and can even drop! That means you get 50 tones per second max, or, if we consider our packet structure above 48 data bits per second! Quite slow 
Edit 3: the previous edit made me think, and basically the maximum speed is going to be something very close to the samples per second, since you could process samples as they become available. I forget exactly what that speed is. I’ll check in a bit and update.
I am officially cancelling this thread about the possibility of transferring data through the audio cable due to the simple fact that the audio chip responsible does not separate the audio between headset and speaker.
That means the device will be mute during the entire game or either will be beeping constantly throughout.
I have decided to cancel all my projects associated with Playdate until further notice.
EDIT: Unless someone somehow is able to pan the left and right channels for both sound effects and data transmission. I will reconsider. This also applies to if Panic allows local Bluetooth connection for Playdates.
IIRC it is possible to use a TRRS cable that splits headphone/mic. I bought one on the advice of Dave when he created a demo of how to do it in C. More info: Direct access to the Playdate's speaker not sure if that is relevant.
Regarding the bleeping, could you not do it at a high pitch that is inaudible to humans?
I'm sad to see you give up on the idea, I really am. Certainly, you and I have different ideas in our heads.
For one, I assumed that it was very unlikely there were two separate hardware channels, one for the speaker, another for the headset. It should go without saying that using headphone for data transmission is a neat hack, but not a de facto way of networking and inter-device communication (-: So, no game sound is a shortcoming, but not a show stopper. It can be a type of a couch-multiplayer game where players' chatter is enough sound already. Especially, for competitive PvP kind of games.
Another reason to keep on looking into this project is that it is a way of communicating with a big brother computer. It can be used for syncing data on-line (contrary to USB disk mode-style sync). That could be employed for some sort of sit-on-desk apps and dashboards. Heck, you can even run an HTTP server and server your little website (or a BBS!) off your Playdate! Beep boop like it's 90x again (-:
I'm just thinking out my ass here. But it's a cool hacker project to pursue for sure.
I already checked the code multiple times and I made it clear that I would want audio sperate from the data transmission through the audio cable. I also chatted with a bunch of people and nobody wants to pull out a dumb looking swapping cable to play.
Plus it costs more money to buy the cables than the game itself. I decided it wasn't worth it or my time developing.
My friend just simply told me to return to it when the features are available by others.
Trust me, I am disappointed too.
Its always disheartening when you have to scrap an ambitious project.
Also I do have the cables to test back and forth microphone and for some reason both duplicate the audio. That shouldn't happen.
