How can I read GPS raw data, to be more specific I need the saellites pseudo range.
This data is not available in NMEA format.
Satellites pseudo-ranges are not available in the official API, neither through the GpsStatus.Listener nor the GpsStatus.NMEAListener interfaces.
The only available info available in the GpsSatellite class are:
PRN
azimuth
elevation
C/N0
a "usedInFix" boolean.
The Android source code asks just those fields from the native code, so no hope to get it from any other Java API.
The best way for you to get this data anyway (which is not suitable for a Market-able application) would be to explore Android source code, and either find a native hook to get the data at low level and access through JNI, or recompile the full OS modifying the API to your needs (you also need to find the relevant native code for that).
Finally, if you can get the chipset to send you GRS NMEA sentences (you would get them through the standard NMEAListener interface, the difficulty is configuring the chipset to send them) you can then compute the pseudo-ranges (those sentences contain satellites' residuals)
Good luck and let me know if you try any of these ideas!
If you need pseudoranges, and raw data, you will not be lucky with NMEA.
You have to use the binary protocol of your receiver,
E.g ublox binary for ublox receivers. Sirf binary for Sirf receivers.
Sattelite raw date are available only on special receivers which have the RAW option enabled. Don´t expect that on a smartphone.
More details you find at the ublox protocol specification.
you might take a look at satinfo
http://code.google.com/p/codetastrophe/source/browse/#svn/trunk/projects/satinfo
not sure if it provides specifically what you are looking for or if it even still works on recent versions of android
Related
I'm writing an Android app that has to perform audio processing (more specifically, MFCC). I have decided to use the TarsosDSP library, but it does not provide a way to pass a sound file to it, as opposed to microphone input. This means that we currently have to write a class that implements a specific interface: basically, it's a wrapper around a buffer of doubles.
Do you know of a way to get the samples as a double from a music file format that Android supports ? We've been scouring the net for a solution but we haven't found one that is generic enough.
Thanks for the help !
I had the same problem for a while and found this:
https://0110.be/posts/Decode_MP3s_and_other_Audio_formats_the_easy_way_on_Android
You can still use the pipe in android. The code in the link allows you pass audio files directly into the decoder. It also contains the ffmpeg binaries required for the assets.
the link takes you through the steps. Good luck.
I'm trying to detect the leakage of private information by inspecting the smali code of Android applications. My strategy so far is.. searching the code that substitutes a personal information (e.g. IMEI, phone number) into a variable, then trace that variable until the point where it's sent to the internet or where it's not used anymore.
Are there any nice tools for doing this?
I've tried
apkinspector (http://code.google.com/p/apkinspector/)
androguard (http://code.google.com/p/androguard/)
androwarn (https://github.com/maaaaz/androwarn)
, but none of these are likely to be able to do what I want.
unpack classes.dex, use dex2jar and inspect with jd-gui, it's somehow simpler, if jd-gui doesn't crash
you can also search for calls to functions needed to obtain some info, like imei How to get the device's IMEI/ESN programmatically in android?
I am currently investigating the implementation of UPnP.
First of all, i luckily found a open-source application that implements
the renderer(DMR) based on the cybergarage library in Android device.
You can find it here:
http://code.google.com/p/stream2android/
(Thanks the developer for this source as my start-up material.)
However, I have some questions below:
The description files puzzle me. Can anyone let me know how to write the description
file .xml? I have searched this topic but not yet found anything can instruct me
comprehensively. what does description file exactly do and how does this file interact
with UPnP?
The project so far implements the renderer(DMR) function and only supports the video
streaming. I want to do it supporting both image and audio media types. What is/are the
key(s) I should pay attention?
Thanks for your reply and instruction in advance. : )
Device description file, well, describes the UPnP device :-) Any device wanting to participate in UPnP network must serve this file in a well known location (URL), so that any other device in the UPnP network can get this XML and know what is the device type, name, serial number and most importantly, what services it implements. I recommend you download the UPnP specs bundle and navigate yourself to documents/UPnP-arch-DeviceArchitecture pdf. This is the starting point for understanding UPnP. It is written very understandably and goes in the exact steps of the device which wants to join UPnP network. Device description is there complete with example and explanation of each single entry.
"Streaming" in UPnP is simply downloading the media binary with HTTP GET. I simplify for the moment because i don't expect you to use any other transport like RTSP or FireWire. So, "streaming" itself is not a problem, you just need to inform the UPnP network that you accept (example) also image/jpeg and audio/mpeg, not only video/mpeg. "the key you should pay attention" is the fact that you must be able to render all that binary data which you asked for. It's not as much about the "streaming" as about having proper codecs and know how to use them on your platform.
I'm writing an Android app that reads and parses NMEA sentences from GPS receiver and using a Nexus S phone for tests.
I'm getting GPGGA, GPGSV, GPGSA and GPRMC sentences that are pretty common and very well documented, but in addition, I'm getting next sentences and I'cant find any info about them:
PGLOR, GNGSA, QZGSA
Where I can find some docs about those sentences format?
The $GN-prefix is usually used when the sentence is formed using several satellite constellations (so far usually Glonass and GPS are the viable options). The $QZ-prefix is a little more unclear but I assume that it is for the Japanese QZSS-satellite constellation.
The rest of the sentence after the prefix is standard NMEA 0183 and contains what the normal GSA-sentence would contain.
The $PGLOR is probably used to produce information and / or configure the locationing chip. Or something similarly uninteresting.
What's really interesting is that Nexus S seems to have a Multi GNSS locationing chip.
Further information here
I recently wrote an app that parsed the GPGGA NMEA strings, my advice is parse what you need, and leave the rest. Generally you don't need all formats, only specific ones.
The first two characters typically define the type of device sending the message, with the last three being the type of message. $GNGSA and $QZGSA should be reporting the same or similar data as $GPGSA, which would be satellite data, including dilution of precision.
I don't know which device these come from, but GN is mentioned here: http://macrogroup.ru/content/data/store/images/f_1072_5353_1.pdf
Regarding $PGLOR... I'm not sure. Perhaps if you could post what chipset is used internally, its documentation could be consulted.
I have to do an application in NFC. My tag return NFC-V, so I cast it in NfcV. And I have to extract some information, and the method getResponseFlags seems contains what I need. But I didn't find any documentation that explains me how read the returned byte. I suppose it is a bitwise of several properties, but in witch order and witch information, it is no where explains.
Where I can get information about this?
PS: I have already searched Google with lot of request, I have also looked in source code and in javadoc, I have also read some PDF about ISO 15693 (NFC-V), but nothing says me for example the bit 5 means "is Afi Locked" (Its just an example, probably not the truth)
You need the ISO15639-3 spec (note the '3') - that one details the required commands & defines the responses, including the bitmasks for the relevant fields.
The response-flags returned by only contain an error-flag (bit 0), and a flag to indicate if there are extensions to the protocol (bit 4). To get information about DSFID, AFI, etc you'll need to use the 'Get System Information' command ('2B')
To get the spec you'll need to pay the ISO organisation 150CHF :-(, but a bit of googleing should find you alternative sources.
Note that RFID-manufacturers can add extra commands to the protocol. For those you'll have to consult the datasheets.