As far as I can tell, it is built on top of RFCOMM which I know to have these properties, so it should also have them. However, I cannot find information anywhere that explicitly states this. Can someone confirm?
Related
Good day!
Problem definition:
Current implementations of Bluetooth does not allow to simply support good quality of Audio(Earphones mode) and 2-way audio transition (Headset mode).
Also, even if one would manage to set this configuration up, which have huge limitations on the hardware/software used, there is no way to handle sound input from 2 different audio devices simultaneously.
So, technically - one cannot just play the Game, communicate on the Discord, and optionally listen to some music, unless he is bound to some USB-bundled earphones. Which are usually really crappy, or really expensive. Or both.
Solution sketch:
So, I came up with an idea that one can actually build such device, using Raspberry Pi, Arduino, or even barebone-component-based stacks.
Theoretical layout of connections per-se would look somehow like that:
Idea is to create 2 "simple" devices
One, not-so-portable, that would handle several analog inputs, and one analog output
One, portable, that would handle single analog Input and Output, and could be used with any analog earphones.
"Requirements" to such system would be quite simple:
This bundle have to handle Data Transition on some distance, preferably up to 10 meters, or more.
The "Inlet" device should be portable enough to keep it in the pocket, or in an arm band, or something
Sound Quality should be at the very least on the level of Bluetooth headphones profile, or if possible - even better
If possible - it would be nice to keep the price of the Solution under 500 Euros, but I'm so tired of current state of things that I might consider raising the budget...
Don't mind the yellow buttons on the Outlet device. Those are optional, and will depend on the implementation stack :)
Question:
Can anyone advice me which component-base would be a better solution to making such a tool, and why?
And maybe someone actually knows of similar systems already existing?
Personally I would prefer anything but the barebone-components-based solution, just because I'm really rusty with that area, and it requires quite the amount of tools, to handle it properly.
While using pre-built modules can save me from buying most of the hardware tools, minifying my "hardware customization" part of this solution, leaving only software part to handle (which is my main area of expertise).
But then again, if there are some experts here, that would consider other stacks non-viable - I would really appreciate to see their reasonings.
P.S. Just to be clear: If this project will prove viable - I will implement it, and share the implementation details with the communities. I am not the first one who needs such system, and unfortunately it seems that Hardware/Software vendors are not really interested in designing similar solutions...
I happen to find a "temporary" solution.
I've came across a wireless headset, that allows to simultaneously support Wireless USB Bundle connection, and Bluetooth connection to different devices, and provide nice way of controlling sound input/output with both connections.
This was almost a pure luck, as this "feature" was not described anywhere in the specs...
Actual headset name is:
JBL Quantum 800
This does not closes the question per-se, as I still plan to implement this "Summer Project" at some point, but I believe this information might be useful to those searching for similar solutions.
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 am fairly new to GNU Radio and the SDR world. I am currently trying to reverse engineer a signal from my Logitech wireless keyboard. Besides the knowledge I gained from my electrical engineering education, I have used various guides to assist me with this project ([1],[2],[3]).
I have been able to record a sample of the keyboard and am able to play it back so that the computer with the receiver thinks it is seeing a keyboard, so I know I have a signal at least. Demodulating the signal is where I am having problems. I know from FCC ID research and the radio chip it uses that the modulation is GFSK, but when I try to do any sort of demodulation in GNU Radio, I am unable to find any usable data.
I have been poking around at this problem for a few months now, and haven't been able to solve it. Any assistance would be greatly appreciated.
[1] Radio to Data: http://www.inguardians.com/pubs/GRC_signal_analysis_InGuardians_v1.pdf
[2] keysweeper: http://samy.pl/keysweeper/
[3] Keyfob hack: http://blog.kismetwireless.net/2013/08/playing-with-hackrf-keyfobs.html
I don't know if this really is a good answer from a StackOverflow Perspective, but I'll try nevertheless:
Whilst GNU Radio has a demod for GFSK signals, it's hard to guess GFSK parameters. You might be a little better off sufficiently oversampling your signal, and having a look at a waterfall visualization of it. Can you see the different FSK subcarriers?
Assuming you do, simply appropriately filter that signal into the FSK subcarriers, and compare their energy.
I was wondering if it is possible to modify the contents of a BLE beacon to include extra information. If you insert an extra bit at the end you could potentially broadcast a boolean in one direction. Theoretically, if you modified your device to read the extra bit of information this would work. Given existing protocols though it sounds like this would be a lot of work. Is there something out there like this already?
For info, I'm working on the mbed platform where you can modify your own bluetooth beacon payload.
Yes, you can do this with the new AltBeacon specification. There is a one byte manufacturer reserved field which you can use for whatever you want (tied to your manufacturer ID).
There are reference implementations of the specification available for Linux to show you how it works, and there is no reason you cannot implement it on the mbed platform.
Many sites and articles on getting widescreen monitors to work on notebooks in their native resolution mention something called the "Mode Removal Table" in the Video BIOS which specifically prevents certain video modes:
http://www.avsforum.com/avs-vb/showthread.php?t=947830
http://software.intel.com/en-us/forums/showthread.php?t=61326
http://forum.notebookreview.com/dell-xps-studio-xps/313573-xps-m1330-hdmi-hdmi-tv-issue-2.html
http://forums.entechtaiwan.com/index.php?action=printpage;topic=3363.0
Does such a thing really exist? The fix worked for me but I wanted to find out if I can read, modify, or work around this table. However I can't find any mention of it in the various VESA standards. Perhaps it actually goes by some other more cryptic name?
“Many sites and articles”? The first couple of dozen results are from you, and most of the rest are from that Intel article you mentioned or other people linking to that article.
You could always try asking someone who talks as though they know how to do it. There's another thread that discusses it—though it too has no information on the table, only a quick mention of it.
There does not seem to be any currently known way to read the GMA video BIOS. You would have to dump the BIOS and reverse-engineer it to figure out where the table is and how to interpret it. Unfortunately, even extracting it is difficult since nobody seems to have had enough interest in creating a tool to automate it. Looks, like you’ve got even more reversing to do. (Techincally, because the GMA is an integrated graphics-adapter, you'll need to extract the video BIOS from the system BIOS, then extract the table.)