Is there an open standard for transmitting M2M data via audio?
Use case example: I want to broadcast a public PGP key via some sort of audio output.
You want to use "Frequency Shift Keying". It works by encoding bits into different frequencies of tones.
If you're doing that on Linux, use Mini Modem (http://www.whence.com/minimodem/).
If you are trying to accomplish this on windows, there are a number of amateur radio tools that transmit FSK signals over a soundcard. Try googling for "Sound card FSK modem"
Just for fun, here's a link to the "Kansas City Standard", which was intend for storing data on audio cassete: https://www.wikiwand.com/en/Kansas_City_standard
I hope someone can provide a simpler solution but so far I've found that a process called modulation was used to transmit data over audio in the days of dial-up:
Data to audio and back. Modulation / demodulation with source code
If time is not critical then DTMF - up to roughly 10 signs or 40 bits per second.
Related
I have a vectorized wav file with values between -1 and 1, 88,200 samples, 44.1 kHz sampling rate to hear the audio within two seconds. I'd like to send the audio through bluetooth to a bluetooth module, arduino, DAC, and 3.5mm breakout board with earbuds.
I am getting crackly audio when I receive it at the end. I tried to recreate this is MATLAB and it turns out to be a combination of the scaling (multiplying + shifting the values over 0) and the sampling rate change due to the receivers. Of course, I could be completely recking the sampling frequency with inefficient Arduino code, but since a factor is also the initial scaling my guess is that I am misunderstanding something fundamental to audio processing.
What is the proper way to format and or scale the values between 0-4095 (which are needed for the DAC input) so that the audio itself is not distorted upon listening due to the scaling factor, sampling rate retention aside? OR is there something else I am missing in the big picture of this?
Clarification: Currently I am using the python sockets library to send an audio string array char by char into an Arduino array and reading them as an integers, then inputting into the DAC. Not sure if python sockets is the best way to go, there should be something better or a more robust implementation of sockets to send the data
UPDATE: I realized that the HC-05 uses SPP bluetooth protocol, which seems to be waaay too low resolution to send reliable audio. I will see if I can send a more compressed audio file, store it in the arduino, then output to the DAC. That could provide more reliable audio.
Have you tried setting in and out values in your samples? I know that video that includes audio, that could be one thing being overlooked, anyhow, that can cause issues for uploading to YouTube. It seems similar to this, because it might not know where to begin and end and it can affect audio too.
Another issue may be the format of the samples, against Bluetooth technology. AAC should probably be the format, but confirm this because I am not 100% sure what all it will accept.
The library has an example for bandwidth:
https://www.arduino.cc/en/Reference/AudioFrequencyMeter
But there are other functions for begin() and end(). You could declare them as variable to your start and end times within the samples, such that one will be the active track at a given time. You could also declare your frequency() as a constant value of 44.1, but you might have to escape the period for that. (It otherwise reads 60 to 1500.)
is there a scenario where we can use the Google Resonance Audio SDK not with headphones, but with real speakers (e.g. mounted in a 360° cyrcle setting)?
Or are all algorithms not working for real speaker outputs?
Thank you!
Currently, Resonance Audio is optimized for headphone playback. For example, HRTF processing is done in the Ambisonics domain, without generating (virtual) speaker signals - this is because it is a much more efficient way of generating binaural output.
However, in the Resonance Audio open source release, the Ambisonic Codec class can readily be used to decode Ambisonics to any arbitrary loudspeaker array. To use that with the rest of the Resonance Audio system, however, it would be necessary to modify/extend the audio processing graph by adding a new decoder node.
Please, feel free to add a feature request and, depending on popularity, we might consider adding that in the future!
I am quite new to LabVIEW and NI devices.
I am working on Active Noise Cancellation Project, where I will be using two microphones input and one loud speaker as output. I have NI myRIO 1900 and CDAQ 9178 devices in our university lab. I need to do real time audio processing, I will collect data from microphone and process it using filtered XLMS algorithm to produce anti noise from loud speaker and other microphone is error microphone. I want to process data so quickly( within 1.7 msec ) so I will have real time response at 44100 sample rate !! My question is , 'is it possible to do with labview ?? and is stream processing possible in labVIEW?? and can I achieve so small audio latencies as mentioned above ??'
I have searched for audio processing objects in labview help. I can only find 'Acquire Sound', 'Play Waveform', surprisingly 'Acquire Sound configuration ' will work only for duration of minimum of 1 second not less than that !!! I can't input the time milli seconds !!!( I am still facing problem installing myRIO, so I have used host computed VI to do this.)
Please help !! Thank You
The thing you should be looking into is the FPGA part of the myRIO. You’re never going to be able to get 1.7ms response time via the host computer. The FPGA can access the Analogue inputs and outputs, so if you can get your algorithm to compile onto the FPGA then it should work.
Yes, it is possible with LabVIEW, insofar as any algorithm you want to code up can be executed by LabVIEW. If you're asking whether there is a library that already exists to do the filtering you're wanting to do, you may want to explore the NI Sound & Vibration toolkit, which is sold separate from LabVIEW, or explore third-party libraries.
The raw waveform mathematics abilities that come with LabVIEW are fairly extensive. You should be able to code whatever transforms you want if you know the base math.
I need to do some NON-STANDARD signal processing operations with an RFID-reader, so I'd like to know if it is possible to extract antenna's individual analog (actually digital samples right after ADC) input signal samples with Motorola FX7500 (if you know how this works on FX7400 or FX9500, please do tell, could be helpful). Samples would be processed in a JAVA-based host computer program.
What I've already tried:
Investigating Motorola's own RFID3 API's possibilities, it doesn't go deep enough to actually get in touch with input analog signal samples.
Using LLRP to its full extent, it doesn't allow analog signal sample access either. RFsurvey-functionality would have been helpful to some extent, but FX7500 doesn't support it either.
Accessing RFID-reader's linux terminal, trying to find the driver function(s), that could listen the input sample stream. If current input sample(s) could be extracted from the input stream, I could (in theory) make a script, that would save a few of those sample values in a txt-file in the host computer during a tag inventory round. My linux skills are kinda bad, hence I ask this question.
The only realistic way to solution seems to be via linux terminal, so if you folks have any ideas about that (where to look and what to do), please advise!
Contents of reader:
rfidadm#FX7500abcdef:/$ ls -1
apps
bin
dev
etc
home
include
lib
linuxrc
media
mnt
platform
proc
readerconfig
run
sbin
sys
tmp
usr
var
I cannot completely rule that out, but it's highly unlikely you can get the raw signal digitized; the devices you're looking at aren't really software defined radio devices, typically.
"speaking" RFID physically is a bit different from "usual" wireless communication: The reader doesn't only observe the energy transmitted from the tag, but more importantly the fluctuations of energy extracted from the near field of the reader's antenna coil. Hence, you don't actually have a baseband of RF bandpass signal, but hardware-specific modulations of transmitted (and inversely, antenna-reflected) energy. Demodulation is hence usually done in specialized hardware.
However, do not fret: It's totally possible to build a software defined RFID reader. There have been several approaches to that, but personally, I trust these based on Ettus USRPs and/or GNU Radio best. Look through the results IEEExplore gives you, eg. this search.
Most probably this is not possible with the Motorola readers. What you can do, is use one of the RFID chipsets available on the market: either the AMS RFID IC's, or the Impinj RFID IC's. As far as I know, both IC's support retrieving the digital samples that are received. They also have a development kit to test-drive the IC's.
I have a situation where I have a video capture of HD content via HDMI with audio from a sound board that goes through a impedance drop into a microphone input of a camcorder. That same signal is split at line level to a 'line in' jack on the same computer that is capturing the HDMI. Alternatively I can capture the audio via USB from the soundboard which is probably the best plan, but carries with it the same issue.
The point is that the line in or usb capture will be much higher quality than the one on HDMI because the line out -> impedance change -> mic in path generates inferior quality in that simply brushing the mic jack on the camera while trying to change the zoom (close proximity) can cause noise on the recording.
So I can do this today:
Take the good sound and the camera captured sound and load each into
audacity and pretty quickly use the timeshift toot to perfectly fit
the good audio to the questionable audio from the HDMI capture and
cut the good audio to the exact size of the video. Then I can use
ffmpeg or other video editing software to replace the questionable
audio with the better audio.
But while somewhat quick and easy, it always carries with it a bit of human error and time. I'd like to automate this if possible as this process is repeated at least weekly throughout the year.
Does anyone have a suggestion if any of these ideas have merit or could suggest another approach?
I suspect but have yet to confirm that the system timestamp of the start time may be recorded in both audio captured with something like Audacity, or the USB capture tool from the sound board as well as the HDMI mpeg-2 video. I tried ffprobe on a couple audacity captured .wav files but didn't see anything in the results about such a time code, but perhaps other audio formats or other probing tools may include this info. Can anyone advise if this is common with any particular capture tools or file formats?
if so, I think I could get best results by extracting this information and then using simple adelay and atrim filters in ffmpeg to sync reliably directly from the two sources in one ffmpeg call. This is all theoretical for me right now-- I've never tried either of these filters yet-- just trying to optimize against blind alleys by asking for advice up front.
If such timestamps are not embedded, possibly I can use the file system timestamp for the same idea expressed in 1a, but I suspect the file open of the two capture tools may have different inherant delays. Possibly these delays will be found to be nearly constant and the approach can work with a built-in constant anticipation delay but sounds messy and less reliable than idea 1. Still, I'd take it, if it turns out reasonably reliable
Are there any ffmpeg or general digital audio experts out there that know of particular filters that can be employed on the actual data to look for similarities like normalizing the peak amplitudes or normalizing the amplification of the two to some RMS value and then stepping through a short 10 second snippet of audio, moving one time stream .01s left against the other repeatedly and subtracting the two and looking for a minimum? Sounds like it could take a while, but if it could do this in less than a minute and be reliable, I suspect it could work. But I have only rudimentary knowledge of audio streams and perhaps what I suggest is just not plausible-- but since each stream starts with the same source I think there should be a chance. I am just way out of my depth as to how to go down this road, so if someone out there knows such magic or can throw me some names of filters and example calls, I can explore if I can make it work.
any hardware level suggestions to take a line level output down to a mic level input and not have the problems I am seeing using a simple in-line impedance drop module, so that I can simply rely on the audio from the HDMI?
Thanks in advance for any pointers or suggestinons!