Flitspaalmelder problemen

[schueler]

De reden dat ik hieraan denk, is dat de plaatsen zowiezo worden afgerond door het 6-byte systeem.
Daardoor zullen we, ondanks de laterale coordinaat te sorteren, plots een aantal gelijke laterale coordinaten krijgen in de lijst.
De longitudinale zullen dan niet gesorteerd staan.
Kan dit kwaad in je zoekalgoritme?

Dit is mijn niet duidelijk...
Het POI bestand staat op longitude gesorteerd. De latitude hoort bij een bepaalde longitude dus daar mag je nog eens niet naar kijken bij het zoeken in mode 1. Pas in mode 2 en mode 3 ga ik kijken naar de latitude.
In mode 1 wordt de check op latitude wel gedaan maar dat is om de code generiek te houden...

(ik denk trouwens dat dit zoekalgoritme makkelijker kan, maar daar zoek ik wel even op).

Ik ben één en al oor
Er zullen altijd wel dingen verbeterd kunnen worden.


Ben

[schueler]

Ik was in mijn pauze even mijn code voor cirkel en kijkhoek detectie aan het bekijken en heb het probleem gevonden. Ik zat te moeilijk te denken :s
Zal het vanavond implementeren en testen...

Het is vaak de kunst van eenvoud wat charmeert nietwaar


Ben

[joeri fr]

less is more

[schueler]

Phoe, daar durf ik zo even gauw geen antwoord op te geven.
Maar ik denk dat het dan al snel erg complex wordt...
Moet dus een keer uitgerekend worden...


Ben

[joeri fr]

Ben, ik heb nog een vraagje.
Ik weet nu dat in de eeprom de positie van een POI is opgeslagen in het formaat xx° yy' zz" met x, y en z een signed char (dus in het 60 delig stelsel voor graden, minuten en seconden).

De gprms string die uit de 406A komt heeft de vorm;
3723.2475
Is dit 37° en 23' en 0.2475 minuten in het 10-delig stelsel?
(0,2475*6/10 = 14,85)
Of 37°23'15" ?
Ik denk van wel gezien ik dit correct op mijn display krijg, maar gewoon om zeker te zijn...

En dan merk ik nog op da de longitude graden een andere afstand in meter betekenen naarmate we op de latitude opschuiven (aan de noordpool is 1 seconde 8m en aan de evenaar 33m). Hiervoor moeten we onze cirkeldetectie aanpassen of het wordt een ellips...

[schueler]

De gprms string die uit de 406A komt heeft de vorm;
3723.2475
Is dit 37° en 23' en 0.2475 minuten in het 10-delig stelsel?
(0,2475*6/10 = 14,85)
Of 37°23'15" ?
Ik denk van wel gezien ik dit correct op mijn display krijg, maar gewoon om zeker te zijn...

Yep. Zover ik weet wel...

En dan merk ik nog op da de longitude graden een andere afstand in meter betekenen naarmate we op de latitude opschuiven (aan de noordpool is 1 seconde 8m en aan de evenaar 33m). Hiervoor moeten we onze cirkeldetectie aanpassen of het wordt een ellips...

Dit is ook al eens door Jaap aangehaald in Nieuwe Code Flitspaalmelder ergens halverwege...
Ik heb daar nog geen tijd en energie in gestoken...


Ben'

[joeri fr]

duidelijk weer erover gelezen
Ik ben bijna door de variabelen, en heb een plan hoe ik de vergelijkingen zou aanpakken, en het begint steeds meer op jouw oplossing te lijken

[schueler]

Hahaha... ik heb het ook niet in één dag bedacht...
Betreft de tan wat atan had moeten zijn had je gelijk. De functie achter de tan is een atan dus de werking blijft hetzelfde. Zal de naam wel even netjes in atan veranderen zodat dat wel duidelijk is.
In versie 1.21 zitten weer veel wijzigingen. Niet zo zeer in het algoritme maar in de leesbaarheid. Verschillende if-then-elseif constructies vervangen door case constructies.

Ben nu bezig met versie 1.22 om daar de laatste bugs eruit te krijgen en vrij te geven.


Ben

[schueler]

Ik weet nu dat in de eeprom de positie van een POI is opgeslagen in het formaat xx° yy' zz" met x, y en z een signed char (dus in het 60 delig stelsel voor graden, minuten en seconden).

Hé, dat is grappig...

Frank en ik hebben de software en firmware niet aangepast naar de schaal van 60. Dus met mijn firmware en zijn software gaat dat goed.
Mocht je de oude originele software gebruiken met mijn firmware geeft dat foute locaties, hetzelfde voor de nieuwe software en originele firmware...

Ik zie geen rede om de code aan te passen. Met de huidige manier heb je meer resolutie ( 10/6 meer ) dus lijkt me juist beter dan de originele aanpak.
Echter moet dit wel even vermeldt worden...!

De POI's zijn overigens niet als signed char opgeslagen... de opgeslagen waarden worden teug vertaald naar signed...

Zijn wel als signed opgeslagen maar op een vreemde manier.... kan makkelijker. Ik heb zitten slapen blijkbaar....
Ook worden de coordinaten opgeslagen in minuten en seconden.
Ik heb alleen ergens bij een optimalisatie slag blijkbaar deze code gewijzigd en verkeerd teruggezet waardoor ik de coordinaten niet vertaal naar minuten en seconden...
Slordig...


Ben

[schueler]

verschijnt 1.20 op het display?

... dat zou op zijn minst 1.21 moeten zijn...
Versie 1.22 laat bij het zoeken naar satellieten rechtsonder een op-en-neer buigende lijn zien. Als dat niet zo is heb ik wat fout gedaan bij het inpakken van de files...
Ook het geluid ( beep ) is korter dan normaal.

Ik ben er achter gekomen dat na het afvallen van de radar het programma vast loopt. Ik weet alleen niet waar...

Ik zal de bestanden die ik gepost heb nog eens nakijken als ik mijn desktop aan heb staan. Dat zal morgen zijn.


Ben