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.
Related
I try to make my application suitable for disabled people.
Most of texts in application is dynamically retrieved from server so I'm not able to predict what content will be displayed.
Is there some list of most common reading issues relating with Talkback?
I found so far: date format, # character, 'OR' vs 'or', 'IT' vs 'it', $1,555.55 format etc. I want to have full support in my app but I cannot find at least the most popular issues.
I'm a word puzzle junky in my spare time, so I've spent a LOT of other spare time working on a helper program that allows wildcards in search patterns. It works great. On my Dell Laptop (i5, 8GB RAM) the search of a 140,000-word "dictionary" for wildcard matches for words has an almost imperceptible and definitely acceptable delay that occurs only if tens of thousands of words are returned. Java rules. So does its implementation of regex and match().
I was hoping to port it to Android. I worked all day getting a more-or-less equivalent app to compile. No chance with given code architecture.
The problem is that leading wildcard characters can (must) be allowed. E.g., ???ENE returns 15 matches--from achENE to xylENE and *RAT returns 22 matches--from aristocRAT through `zikuRAT--i.e., all 140,000 words must (?) be searched, which is going to take aaaaaaaaawhiiiiiiiiile on most (all?) Android devices. (Each took less than a second on my laptop.) (It takes my PC 3 seconds to return all 140,000 words and a little longer to eyeball them all.)
Since some word puzzles allow variable numbers of letters in words, disallowing leading wildcards cuts the heart out of the app for such puzzles. But if the search pattern had to start with a letter it would be easy enough to then do a binary search (or something quicker). (And it still might be unacceptably slow.)
Anyway, I was wondering if anybody might know some algorithm or can think of some approach that might be applied to speed up searches with leading wildcard characters.
I believe that the optimized version of what you are trying to do is widely known as the Unix/Linux utility "grep", which, if I remember correctly, uses the Boyer-Moore search algorithm.
Under the covers, Java's Pattern class uses Boyer-Moore. And it supports regex, so if you can write something to turn your wildcard search patterns into regular expressions, you can use Pattern.
There's an interesting Java implementation of grep at http://www.java2s.com/Code/Java/Regular-Expressions/AnotherGrep.htm
It uses memory-mapped files. I'm guessing that you won't be able to fit your entire word list into memory, but you could split it up into a bunch of smaller files - the implementation above memory-maps one file at a time. You'd have to do some testing to find the optimal size of a file.
I just Googled and found having a second list reverse alphabetized might be a way to then have a leading wildcard become trailing, opening door to binary search for pattern start. Interesting. But *a???ene* is also a legal search pattern in the program. What then? (Yeah. How often would you need such a search.)
I just found this about Apache Lucene:
Leading wildcards (e.g. *ook) are not supported by the QueryParser by default. As of Lucene 2.1, they can be enabled by calling QueryParser.setAllowLeadingWildcard( true ). Note that this can be an expensive operation: it requires scanning the list of tokens in the index in its entirety to look for those that match the pattern.
Context
I am currently building an sdk/service on wich applications can access to voice based command,
For the moment i'm using android pocketsphinx to detect a keyword (which is "wake"), and then analyse whole sentence with google voice recognition,
But my problem is i want to make it all offline! So i'm in my way to replace google voice recognition by a full utilisation of pocketsphinx...
My Problem
The user define which is the word he want to detect, and previously i just compared the said-word and what google voice speech-to-text returned me...
So know I want to update the grammar that pocket sphinx use with just the word given by the user, which problematic because (following the javadoc of android pocket sphinx) it can only take grammar files!
Question
Are there any way i can update android pocketsphinx grammar on the fly?
Edit
I forgot to talk about this method:
public void addFsgSearch(String searchName, FsgModel fsgModel) (in github pocketsphinx)
wich seem to deosn't take a grammar file like any other grammar setter method, but rather a class/struct? but the problem it's it isn't documented.....
If you need to detect just one word, consider using addKeywordSearch.
I had the same issue, and more. Perhaps these undocumented discoveries can help you.
Using the overloaded method "addGrammarSearch(String name, String fsgString)" allows you to put your entire FSG or JSGF grammar definition in a string, rather than sourcing it from a file if you wish (only a small file open/read time advantage).
"addKeyphraseSearch(String name, String keyphrase)" // only accommodates ONE WORD or PHRASE, no threshold, no grammar.
"addKeywordSearch(String name, File keywordList)" // accommodates MULTIPLE key WORDS or PHRASES, adding thresholds for each.
Several caveats include:
The grammar searches use JSGF format, parsing the defined syntax correctly. However:
1.1 Tags are not implemented
1.2 Unclear if weights (though the same // syntax as in keyword lists) actually apply recognizer thresholds (they have different meanings in PocketSphinx versus Sun Microsystems).
1.3 Rule names are also not implemented either.
1.4 In other words, you provide a grammar in JSGF, and your Hypothesis as well as FinalResult strings still give you the recognized lowest-level phrase detected in the grammar -- NOT the grammar tags, nor even rule metasymbols.
1.3.1 IMHO, that makes grammars pointless, and actually less efficient and less flexible than keyword list files (which are actually words or phrases) due to the option to provide a threshold for recognizer scrutiny, per phrase. Further, if the RULE & TAG names are not returned, then there is zero information regarding the structure of the grammar that was recognized. So as syntactically complex and flexible as it is, I do not see the advantage of bothering with a grammar definition at all in PocketSphinx; the best multiple keyphrase approach is simply to expand your grammar into a keyword list file. Please correct me if I am mistaken.
Search methods, whether containing the word "phrase" or the word "word", actually accommodate both phrases or single words.
I have assumptions re: the undocumented fsgModel class, but we're not allowed to give assumptions.
Though this may help clarify some aspects,the above fails to add any functionality to the package. Lastly, the C source code has methods getRuleName() and getTagName(). But, discussions regarding this topic between users and developers seems to stonewall -- their is no motivation to add tags or rule name associations to recognized words or phrases in a defined grammar, apparently because the developers believe grammars are old-school and nobody uses them anymore.
This question is not specific to Android but I have included the tag.
I need to be able to store phone numbers in some sort of standard form (ideally a string) where equality can be tested/evaluated quickly (hence a string would be ideal)
I found some answers already, the best ones pointed to http://developer.android.com/reference/android/telephony/PhoneNumberUtils.html (I'm fine with using a library to do it for me)
BUT this isn't really good enough, I've tried a variety of format numbers, learnt about the Editable factory to use some of the static methods in that class, but they don't seem to return the form I was expecting.
I was expecting something like a phone-number-hash, that two inputs representing the same number would yield the same in this "standard form" and that one could dial this standard form and be fine. I thought that all the various +s and whatnot would be short-hands for this standard form.
I'm not sure if such a thing exists now.
I understand that some things mean "current area" (or country) which is why land-lines can ommit area codes, I expected a function that would return the format for the current location (but this doesn't apply to mobiles, if it were a land line to prepend the area code for example, this would be (closer) to the "standard form" I keep assuming exists)
I am pretty sure that some full-form for phone numbers exists, thinking about how the telephone system works (which I infer I admit) there ought to be a form that identifies a number uniquely across the whole planet, and when this is not the case (such as local calls from land-lines without area codes) it is an optimisation.
So I have two questions:
How can I "expand" a phone number to a unique string for that number, such that any alternate forms of writing that number (with spaces, an 0 or +44....) "expand" to this unique number?
Are there any ISO(/IEC?) (what's the O stand for?) standard documents with drafts open to the public? I've read the Wikipedia page (ages ago, I've spent so many hours wiki-browsing, and opened hundreds of tabs) but it covers history, or some information on formatting), I'd like to know more about the thing I've taken for granted now for some 8 years or so.
Additionally, why is Windows Phone 8 a tag? To make the 12 proud Lumina owners not feel left out? (It was suggested as a tag!)
Addendum
Unfortunately Any API in android to normalize phone number there are no solutions there (this includes libphonenumber) and my quest to find out has lead to some interesting reads:
http://en.wikipedia.org/wiki/Panel_switch
http://en.wikipedia.org/wiki/Nonblocking_minimal_spanning_switch
http://en.wikipedia.org/wiki/Telephone_exchange
and I still cannot conclude there isn't some "full form" for numbers.
I dare not create a solution that simply swaps +44 for an 0 and such.
After reading your question, I was reminded of Google's library called libphonenumber. Its Google's common library for parsing, formatting, storing and validating international phone numbers. It does the following things ( some of which seem what you might be able to use):
Parsing/formatting/validating phone numbers for all countries/regions
of the world.
getNumberType - gets the type of the number based on
the number itself; able to distinguish Fixed-line, Mobile, Toll-free,
Premium Rate, Shared Cost, VoIP and Personal Numbers (whenever
feasible).
isNumberMatch - gets a confidence level on whether two
numbers could be the same.
isPossibleNumber - quickly guessing whether a number is a possible
phonenumber by using only the length information, much faster than a
full validation.
isValidNumber - full validation of a phone number
for a region using length and prefix information.
AsYouTypeFormatter - formats phone numbers on-the-fly when users enter each digit.
PhoneNumberOfflineGeocoder - provides geographical information related to a phone number.
As far as international format of phone number is concerned, E.164 format is an recommended by International Telecommunication Union. It defines a numbering plan for the world-wide public switched telephone network and is a general format for international telephone numbers ( usually stats with + followed by country code, Area code and the number).
Using the above library, validity of all the phone numbers can be checked if you mention the international code along with the phone number ( example 1 for US & Canada). If you don't have the code but you know the country's name for which you want to check the number, then also you can validate. You can also convert all the valid numbers of 1 standard E.164 format using this library. You can also 'expand' a number in Local National format of that particular country. You can save it as String as well. Although it does use PhoneNumberUtils that you mentioned in your question.
I am not sure if this is what you are looking for but I hope this information helps you.
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