I'm wanting to create an Android app that will send IR signals, but I don't know how to find the signal patterns or the frequencies from the original transmitter.
I purchased a small USB IR receiver (not Microsoft, but uses the Microsoft EHome drivers) and I can see the patterns from WinLIRC, but they are barely consistent, and trying to use any of them doesn't work on the receiver. I also am not sure what frequency to transmit on. I have my app sending back the signals and I can see them in LIRC, and they're accurate, but the receiver from the original remote doesn't respond to it.
How can I get the info from the original transmitter, accurately, without spending tons of money on something like an oscilloscope?
Related
I have an application that needs to use a high-quality microphone and headphones simultaneously. On my phone, there is only one input for an audio device. How can I connect to and handle in/out data from each?
edit: I dont want to capture two input sources at once. I want to record from a microphone, use it to modify audio which i have already recorded, then output the result to a headphone in real time. I know this is possible, however I dont know how to connect and differentiate between two devices connected to the audio jack via a splitter.
Most (probably all) Android devices with a 3.5mm port support a TRRS connector(https://en.m.wikipedia.org/wiki/Phone_connector_(audio)#TRRS_standards)
So there is a different hardware channel for the microphone and the headphones, and it's not possible to accidentally use the wrong one in software or for that matter manually select what to use the hardware connections for, it's predefined.
But so the point is that you need the right splitter exactly for this, not just a normal audio-splitter but one that specifically splits the input/microphone channel from the output/heaphone channel.
If you use the search term "audio and microphone 3.5mm splitter android", then you should find the correct splitter hardware shopping recommendations:
https://www.google.com/search?q=audio+and+microphone+3.5mm+splitter+android&tbm=shop
Here is an example picture:
The protocol IEC 62056:21 tells us how to deal with enegy meters, it's quite easy!
The part where I am stuck is the implementation over a GSM data channel. Normally I would set things like:
300 baudrate
1 parity bit (even)
But the meter is not connected via serial connection but, instead, it has a sim. Using a modem I can call the meter using:
AT&C1
ATDNumber
Problem 1: Settings
The modem calls the meter with different settings (baudrates, stopbits, parity) compared to the protocol ones, e.g.
9600 baudrate for call
300 baudrate for first messages
xxxxx new baudrate shared between master and slave
Can I change these parameters during call?
Problem 2: Send data
After I establish a call, I would send to the meter things like:
/ ? Device address ! CR LF
Here's the missing piece, I don't know how to send this data over the call
I am reading and trying several libraries (like J62056, pyserial), but I've found nothing about sending data via gsm call
EDIT
I read a trace of a proprietary software, and I got this:
TX: 140ms AT&C1E0V0
RX: 32ms 0
TX: 1203ms
ATDT ##########
RX: 34656ms 1
RX: 0ms 5
RX: 0ms
TX: 3234ms <NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL> *what is this?*
TX: 594ms /?########! (this the Request message) **start sending data**
The < NUL > part is not Clear, and this is where the modem starts to send data
Edit:
I read about the 8 null chars, they're just a check-in sequence.
At the moment, after the modem established the call I translate my 8 bit no parity sequence into a 7 + parity one. Now i am able to send and receive data from the meter, I must test other feature before writing my solution to this answer
Without knowing anything about IEC 62056:21, if your energy meter supports this over GSM circuit switched data (CSD), nothing it says about speed and parity in the normal non-GSM case is relevant at all.
Because the data call you set up will be non-transparent CSD (NTCSD). A transparent call would have treated the gsm connection as much as just an electrical wire as possible (which in best case is difficult1), forwarding each byte received immediately and with no buffering nor with any retransmission support. A non-transparent connection on the other hand will receive/send its data to an intermediate entity which in turn communicates with the other end point, and will support buffering and retransmission.
For GSM NTCSD, the part of the phone responsible for data handling is called TAE (Terminal Adapter Equipment) or TAF (T. A. function), and the relevant protocol2 is called RLP (Radio Link Protocol) which is specified by 3GPP in specification 24.022. It is a link-layer protocol similar to HDLC, and it communicates with a unit in the GSM network called MSC (Message Switching Centre). It is then then MSC which communicates with the other end, on a different and completely separate communication line (which can be PSTN, ISDN or mobile network depending on what kind of device the remote end is).
mobile modem <----link1----> MSC <----link2----> remote endpoint
The important thing here is that the two links are 100% independent, and they do not have to be the same speed.
Thus whatever speed your energy meter is using over some serial interface between itself and the embedded modem with SIM card is independent of the radio link1 speed which itself is independent of the network link2 speed which your modem will have.
So the above should be an answer to your question, but let me fill in some more information with regards to the speeds of link1 and link2, because this can be controlled with two AT commands AT+CBST and AT+CHSN (specified in 27.007).
The basic GSM data traffic channel is called TCH/9.6 (Traffic Channel), which is a channel with net 9600bit/s speed (seen by the user) and 12000bit/s gross speed (seen by the network). In order to enhance throughput
HSCSD (High Speed CSD) was developed which introduced a new channel coding and a new channel TCH/14.4 which had 14500bit/s gross speed and 13200bit/s net speed (which of course all the marketing people presented as 14.4 speed even though that not was really true).
In addition HSCSD allowed for bundling multiple timeslots together (multislot). A frequency band in GSM is divided into 8 timeslots, where an active call occupies one timeslot in the downlink direction and one timeslot in the uplink direction. Thus a cell tower configured to support only one frequency band supports maximum 8 simultaneous calls.
What HSCSD introduced was the possibility to set up a call that could use multiple (adjacent) timeslots, for instance two downlink timeslots and one uplink (denoted 2+1). The different multislot configurations a phone or network supported were categorised in multislot classes3 (with 2+1 being multislot class 10 as far as I remember).
Since HSCSD both was an added value and occupied more network resources this was something that was billed higher than a normal 1+1 9600 call, and thus the users had to have some control over if they used HSCSD or not. This was
done by introducing the AT+CHSN command which controls the link1 speed.
Support for hinting to the MSC what speed it should use for link2 was implemented by the AT+CBST command (which already existed before HSCSD).
Since the AT command is terminated in the mobile phone, its value had to be forwarded to the MSC in some way, and this was done out-of-band (with regards to the RLP data link) in a Bearer Capability Information Element in some of the call setup messages.
So, that's probably more than you need to know about speeds in a GSM network for a NTCSD call, but having developed and maintained the NTCSD call stack in Ericsson's mobile phones for over a decade, this is something I know quite well...
1
While there are standardized some support for transparent data, this was more of a legacy thing done in the 90-s in order to support equipment made in the 80-s. Operators do not want to have this supported today because it is a pain in the butt to get working and to support.
Fax over GSM for instance was such a transparent bearer, and it was a massive test everywhere approach with no guarantee that it would work even if you followed the specification fully. You had to do your best effort implementation and then you had to travel all over the world testing it and try to fix all the issues that would pop up (which they absolutely did. And even if the problem was something wrong with the network, the operator might not want to fix it so you had to add some custom workaround).
One of the guys working with fax support told me that in some cases they had to start sending the response before they had gotten the request in order for the timing to work out (e.g. they had to guess and anticipate what the remote fax would do).
It is not without a reason that phones manufactured and operators today do not support fax like they did in the 90-s, early 2000.
2
In addition there is L2RCOP which is just a framing adoption between packet based RLP and the physical serial interface.
3
CSD and GPRS both supported multislot, but not necessarily the same class, i.e. CSD multislot class is independent from GPRS multislot class.
Q. What are your best practices in managing bluetooth connectivity?
I've read the android bluetooth guide & many bluetooth connectivity tutorials. Not helpful with encapsulation-design nor best practices.
When should I open/close the connection?
Is the "connection" with a single bluetooth device called a "socket" connection?
Can a single connection send data while listening? (...or between listening states).
I've never coded connectivity with external devices before. It took two weeks for me to wrap my head around the code that scans for near-by bluetooth devices and throw them into a ListView. Listeners, Broadcasts, and Adapters!
My project will be printing 1-40 receipts every 15 minutes on a bluetooth receipt printer. At the moment, security is not an issue. On the same connection, it will also be receiving data (sending & receiving simultaneously does not appear to be necessary but would be useful). I'm not yet sure how the devices are configured on this single dongle device but I would guess the devices are connected via USB controller to the dongle.
So far, I have 1 object to manage a single I/O connection. Staticly I open an activity to select a connection (to later save the label, mac, and pin in the database). Based on tutorials, I have "open", "listen", "send", and "close" methods. What confuses me is "how" to use these functions. Can I leave a connection open all day (10hrs) and use it every 3mins? Should I open/close the connection when sending or requesting data? Where would I detect the need to reconnect?
sorry for the short answer, but from my practice with the Bluetooth API, I have found that this video describe the things very good (totally personal opinion...)
Video 1
In addition this is useful when you do NOT have any previous experience
Tutorial
And as last check out this question in stackoverflow it has a bunch of good references and examples!!
Again sorry for the shortage, but I believe that if you check these out at least most of your questions and concerns will become answered!
:)
EDIT
So, let me be a bit more descriptive and share some of my experience.
I have written an App that communicates with BLE device that has 3 functions
double sided event driven button (push the button on phone -> event is fired to the device; push the button on the BLE device -> event is fired to the phone)
send request from phone -> BLE device answers with current battery percentage
continuously reading strength signal (as aprox. distance) between the phone and the BLE device
So far so good, now the things is that the basic approach is:
Search for BLE devices (bluetooth search or "discovery" of nearby bluetooth devices)
Here you will need android permissions!
Choose the device you want to connect to
To differ the devices (maybe there are a lot around you :) ) you can use BLE device's name or UUID or ... best - use the name ;)
After both devices connect to each other you can then start the Gatt communication. The approach with state machine is a little too much overkill for me. But anyway the communication is done through bytes (in my case...)
In one of the videos/resources there was something specific and VERY HELPFUL at least for me! To be honest I don't remember it exactly, but the idea was that before any communication it's RECOMMENDED to read/get all the options from the BLE device or something similar...
Maybe it was something like discoverOptions() or something like that
Great thing will be to know your device "communication codes" or at least I call them that way.
Check this link for example: Link
** Now you can see there are tables with the USEFUL INFO! E.g. if you want to read the battery level you navigate to this page and find that in order to read the battery, the service name is UUID XXXXX and you need to send 0x01 to the BLE device and it will "answer" to your call with some data which is again in bytes.
I really hope that this is somehow helpful!
PLEASE NOTE
This is strictly coming from my experience and there could be some mismatches or wrong terms, but that's how I personally see the things and because my project was long ago, I don't remember most of the things exactly.
IMPORTANT:
This is only a summery of STUCI's provided links above. He has since updated his answer and I have not updated/edited this summery. Topics in my summery are not explanatory but provided for reference and help in generating specific questions.
Original Post...
Thank you Stuci! Some of that was helpful:- some not. I thought it best to collect my thoughts and see what has been explained and if anything hasn't.
(I can't post this much in a comment tho, sorry)
PLEASE CALL ME ON ANYTHING THAT IS INCORRECT.
Video of Bluetooth LE
(Covers a bunch of random things)
While I "dont-like" videos of code:- I watched it because it was recommended ... and I am glad I did. While not very helpful it did introduce some concepts I was unaware of. Since I am targeting old android devices (v8+) the LE features are inconsequential.
Pushing Data: [Depending on the source feature-set], one does not need to continually pull data (ex. with a temperature sensor) but some devices can "push" it to the device on change. Seems to use the 'advertisement" design concept.
UUIDs define Services and/or Characteristics of the connected device.
Possibility to write configuration on (to) connected devices.
Characteristics which seem to be simply "settings" that can be assigned over bluetooth. Not sure if this (~19mins) applies to non-gatt connectoins but seems similar to the state-machine that controls
Advertisements which seem to be the "metadata" regarding the devices current state or config (~24mins). Again, not sure if this even applies to non LE Bluetooth.
Leaving Connections Open
Bluetooth connections can indeed remain open; starting at the point which the "startActivityForResult(...) method is successfully called.
Two basic things affect whether or not one would want to maintain an open connection:
Understand the power consumption.
Having the adapter active simply consumes additional power. If one can keep the adapter shut-off while it is not "absolutely-needed" will mearly save battery power.
Accidental disconnects are managed.
Other than leaving the connection continually connected, one could disconnect & reconnect regularly at specified intervals to ensure a connection is up.
In the thread(s) used for I/O, one could check for a disconnect and reconnect (possibly starting a new thread).
I/O Streams pr Connection
A single connection can indeed "have" simultaneous Input & Output streams. I
Since it was suggested, I re-read Android's Bluetooth Guide and under "managing a connection" (talking about a single socket) I noticed this...
Get the InputStream and OutputStream that handle transmissions through the socket, via getInputStream() and getOutputStream(), respectively.
Read and write data to the streams with read(byte[]) and write(byte[]).
...but continues with noting that read & write block each other. Something I still need to look further into. It seems like you cant I/O simultaneously on the same socket???
Max Connections
I also looked into the max connection issue Stuci added and found no documentation on the Android-side. It might exist, I cant find it. However, most people seem to agree that there is a limitation (that could be as low as 4) imposed by whatever hardware you are coding for.
Some notable links:
- How many devices we can pair via Bluetooth of BLE to Android?
- How many maximum device can we pair via Bluetooth to android device at a time?
- https://groups.google.com/forum/#!topic/android-developers/adeBD275u30
I'm new to adaptive bit rate streaming. Basically I'm trying to write an app that shows information about the quality of the connection on an Android device.
Since HoneyComb(3.0), Android supports adaptive bit rate streaming through HTTP Live Streaming (HLS). It seams like support for helping developers verify the quality of this connection device side is very limited.
What I would like to know is some low level information about the stream. Such as: the number of segments, the segment duration, number of requests to change bit rate, the bit rate the media player sees (to facilitate the change), etc.
I've been able to get some information about stream quality from the MediaPlayer, MediaController, MediaMetaDataRetriever, CamcorderProfile, MediaFormat, MediaExtractor classes. However, the stuff I'm looking for is even lower level. If possible I'd like to be able to actually see how the player is communicating with the server.
I just started looking at the MediaCodec class, however I can't figure out how to get the MediaCodec from a mediaplayer. Or Maybe I just don't know how to use this properly as I cannot find any good documentation and examples.
Does anyone know if it is possible to access the low level information on the Android that I'm looking for? Is the MediaCodec the way to go? If so, does anyone have any working examples of how I could get the currently used MediaCodec and extract the information I'm looking for out of it? (Or at least point me in the right direction)
Really appreciate any help on this one.
Cheers
Is there a way in java, or even C++, to send current depending on how much sound is playing?
Let's say, if there is a lot of sound playing, the USB port will be receiving 20mA, and if there is very little sound, the USB port will receive 5mA, and if there is no sound, obviously 0 current / voltage. You don't have to go too in depth with your response. Just maybe point me in the right direction and help me get started.
I do prefer java over C++, that would be great.
Thanks!
This in the proposed form is not doable. The power supply is either turned on, or off, but not in between. without hardware you can not make a LED sound meter out of it...
However, it would be fairly easy to accomplish this using commercially available, USB ready building blocks. There are multiple options, but I'd prefer an Arduino. Connected to the USB port, it can be connected as if it was a serial port, and that is nőt very difficult to do. For this, you need these to be done:
get an Arduino
write a sketch in C that accepts your input, lets say ASCII encoded decimal integer values, and does the function you want, like power a LED through PWM pin with variable duty cycle (Arduino side)
write your code, that acquires whatever you need ("how much sound is splayed", whhatever that means...), on the PC side, in whatever language you prefer
send the numeric values to the Arduino using serial port communication from the PC side code
No. The hardware does not support this functionality. The USB port is not a DAC.
i think both are good, unless you know the concept the language u going into.
but still, i'll prefer java beacuse of simple coding.
you can use sequencer or mixer and can send it to the port you want.
mixer can handle sending/reciving multiple midi events.
but in java , sound API is not much advance, but in c++ u can use
python's large liabrary,which can help you to get the frequency
or voltage.where as in java,functions are limited,
and at time's you need to add external liabrary or preform
FFt(i hate this part).
that's it! good luck