Back
[05:38:45] <Lambda_Aurigae> http://dangerousprototypes.com/blog/2016/07/23/inverter-crystal-oscillator/
[05:38:56] <Lambda_Aurigae> for those who wonder how a crystal oscillator works.
[05:40:04] <Lambda_Aurigae> http://qrp-popcorn.blogspot.com/2016/01/inverter-crystal-oscillator.html
[05:40:06] <Lambda_Aurigae> full article
[06:07:39] <kre10s__> neat!
[08:31:19] <bedah> hi
[08:32:04] <bedah> i need some inspiration, to parse GPS NMEA data wir avr-gcc. should be lightweight, fast and some kind of maintainable
[08:32:36] <liwakura> parse into what? two floats?
[08:34:06] <bedah> maybe.. two int32 for lat/long, one for height, and all other data like velocity, satellites in sight
[08:34:32] <bedah> http://imgur.com/wCje2WD this is how it looks now, simple as can be
[08:35:30] <bedah> i might get up to 16 records about satellites in sight
[08:36:27] <bedah> int32 because that could fit 100th of arcseconds into 32 bit data, without divisions
[08:37:10] <bedah> so.. floats etc is not the issue, more like "how to parse some strings with lots of different kinds of values"
[08:37:15] <liwakura> mh
[08:37:33] <liwakura> some sort of interating
[08:37:52] <liwakura> if you do the math beforehand, you could parse it character-by-character
[08:38:17] <bedah> could be floats later, too.. that's why it should result in clear code. last time i tried to parse gps, i got some deep nested if/else/case, parsing character by character
[08:38:35] <liwakura> would you know a better way?
[08:39:02] <liwakura> you could try using the fscan functions from the avr-libc, but those just hide the giant if/else stuff behing a abstraction
[08:39:08] <bedah> i could collect one line at a time, 80chars maximum sentence length for gps, and parse them afterwards
[08:40:33] <liwakura> and later then, parseLine( ... ) which does nothing if the Line is not an location set
[08:40:34] <bedah> crazy way would be: some kind of switchable callback functions, which decode char by char, and depending on position in string changing the functions to be called
[08:40:58] <liwakura> callbacks on AVR :(
[08:41:11] <bedah> i works great :)
[08:41:25] <bedah> as long as there is no recursion etc
[08:41:52] <bedah> but code is unreadable
[08:42:00] <liwakura> how much baud is your stuff?
[08:42:21] <bedah> only 9600 baud, the code now has a simple fifo ring buffer
[08:42:21] <liwakura> ah, standard says 4800
[08:42:25] <liwakura> oh
[08:42:31] <liwakura> whatsever, still pretty slow
[08:42:40] <liwakura> i would do an state machine
[08:42:50] <liwakura> like, some struct which yields the current parsing information
[08:43:12] <liwakura> and every time a char comes in, i would quickly process it in an interrupt or sth
[08:43:14] <bedah> yes but.. the gps module (ublox neo 7m) can be configured to send way faster
[08:43:50] <bedah> right now the interrupt just pushes data into the fifo
[08:44:05] <liwakura> hm, depends on what the other parts of the AVR do
[08:44:25] <liwakura> per-line buffering would also be a nice solution
[08:44:40] <bedah> yes definitly
[08:44:51] <liwakura> the number parsing will be either with big floats and the cpu expensive float emulation
[08:44:56] <liwakura> or you do some math tricks
[08:45:47] <liwakura> hm, yeah, line buffering would be much easier
[08:45:57] <bedah> math trick is: convert on the fly to 1/100th of arcseconds - the lowest resultion of the recieved gps data. more accurate than 32bit float
[08:46:26] <liwakura> when you parse it digit by digit, you need to know what to add to your int32
[08:46:33] <bedah> yes
[08:47:19] <bedah> the longitude/latitude data is zeropadded, so there should be no problem to convert it
[08:47:36] <liwakura> also. 5307.147 N doesnt look like some sort of degree to me
[08:48:02] <bedah> 53°05'14.70" north
[08:48:38] <liwakura> oh shit
[08:48:45] <liwakura> so not even consistent bases
[08:48:50] <bedah> yes :D
[08:48:56] <bedah> base60 :D
[08:49:28] <liwakura> is this location supposed to be somewhere near "Hellwege" ?
[08:49:32] <bedah> the great thing is: everything is well documented
[08:49:55] <liwakura> *scratches head*
[08:49:55] <bedah> yes, that's near here, "rotenburg" is the town
[08:51:46] <bedah> hm.. collect one line. check this simple XOR-CRC. find out which GPS sentence. call corresponding function.
[08:51:59] <liwakura> my next step would be parsing it in groups of 2, those 4 would fit inside an uint8
[08:52:09] <liwakura> and then magically calculate them together to that uint32
[08:53:02] <liwakura> also, the lat and long will have to be handled differently, bc one goes from -180 to +180, the other only -90 to +90
[08:53:09] <bedah> yes
[08:53:21] <liwakura> this is complicated and im lazy.
[08:53:39] <liwakura> how do you intend to use that data?
[08:54:07] <bedah> i want to parse it, and then display it nicer on the display
[08:54:58] <liwakura> display it on the usualy float number system or the int32 one?
[08:55:04] <bedah> later some points-of-interests should be added, i want to see direction and info about the nearest ones
[08:55:29] <bedah> first int32, later maybe some float
[08:55:36] <bedah> step by step :)
[08:55:45] <liwakura> i would recommend using floats there, bc there is already much available to print them and parsing
[08:55:52] <bedah> interesting might be a view of the satellites in range
[08:56:19] <liwakura> i guess getting a proper int32 out of the nmea data is more complicated than just getting a float
[08:56:25] <liwakura> s/guess/think
[08:56:54] <liwakura> for the int, you need range mapping, which will make parsing a bit more difficult
[08:57:23] <liwakura> if you just need float, you could so sth like, a * 3600 + b * 60 + c to get the float from the values or sth
[08:57:39] <liwakura> but would need significant more cpu
[08:58:08] <liwakura> i just pulled the fixed numbers from nowhere, pls dont use them
[08:58:30] <liwakura> i dont know much about numbers with quotes in them.
[08:59:27] <liwakura> hm, you could create the int32 the same way, but then the rendering as float would be much more of an hassle
[08:59:41] <kre10s__> liwakura, why would it be easier to get a float than a u32?
[08:59:45] <bedah> i thought about parsing long/lat char by char like "value= value*(conditionX?6L:10L)+nextchar" or so
[09:00:29] <liwakura> kre10s__: the range mapping
[09:00:44] <liwakura> wait
[09:01:12] <liwakura> kre10s__: yeah you are right
[09:01:39] <kre10s__> if the number you want to get does not fit in a uint32... you can't get it with a u32 period. it wouldn't be just 'somewhat harder' :P
[09:01:42] <liwakura> if you define 1 in the int32 as 1 arc second, it should be fine
[09:02:03] <liwakura> kre10s__: i thought you would have to do an range mapping
[09:02:26] <liwakura> bc of overflow effects if you happen to be near 180E/W or 0N/S
[09:02:32] <liwakura> * 90N/S
[09:02:33] <kre10s__> can I see a complete nmea msg?
[09:02:43] <liwakura> http://imgur.com/wCje2WD
[09:03:30] <liwakura> bedah: i was wrong about the float, just use int
[09:03:42] <liwakura> and define the int as being the number of arcseconds
[09:03:45] <bedah> i could easily store 1/1000th of an arcsecond in int32
[09:03:49] <kre10s__> :( like as text.
[09:03:54] <bedah> says my calculation
[09:04:17] <liwakura> kre10s__:
https://en.wikipedia.org/wiki/NMEA_0183#Sample_file
[09:04:21] <liwakura> bedah: neat.
[09:05:20] <liwakura> also, if you have that num, you will only need a static multiplicator to get the degree value, in a decimal-comma form
[09:05:24] <bedah> www.ebay.com/itm/131748309223 this is the cheap reciever. really easy to use
[09:05:26] <liwakura> which is an accepted form for google maps
[09:06:22] <bedah> so.. i'll try my luck, and will report back :)
[09:06:29] <liwakura> see ya
[09:06:43] <liwakura> s/multiplicator/factor/
[09:13:07] <kre10s__> Apparently there's a spreadsheet published by the UK that will calculate the other formats for you. maybe helpful for testing.
http://gpsworld.com/what-exactly-is-gps-nmea-data/
[09:16:46] <bedah> nice, thanx
[11:43:03] <catphish> does there happen to be a channel for the discussion for atmel arm MCUs?
[11:43:33] <Lambda_Aurigae> try #arm ?
[11:44:06] <catphish> makes sense!
[11:44:28] <Lambda_Aurigae> or ##arm
[11:44:31] <Lambda_Aurigae> both have people in them.
[11:44:53] <catphish> thanks
[11:45:11] <Lambda_Aurigae> welcomes.
[12:03:06] <Tom_itx> #edev is arm in general
[12:03:53] <Tom_itx> #stm32 is well.... stm32 arm
[12:21:27] <CasperAtWork> Tom_itx: are you sure about that #stm32? it could be... something else! :D j/k
[13:40:41] <Lambda_Aurigae> CasperAtWork, sure you aren't thinking of #std?
[13:48:16] <CasperAtWork> probably not