Flitspaalmelder perikelen.

[thijsbeckers]

O, misschien ten overloede: het alarm gaat af als je een POI tot op ongeveer 500 meter bent genaderd...

[jaap57]

O, misschien ten overloede: het alarm gaat af als je een POI tot op ongeveer 500 meter bent genaderd...

Ja Thijs, dat had ik uit het artikel in elektuur begrepen.
Helaas krijgen Ben en ik het alarm nog niet aan de praat.
Ik heb in verschillende formats mijn huislocatie in de database gezet maar helaas....

[jaap57]

Het probleem is nu opgeschoven. De EEPROM wordt volgens de PIC nu braaf geladen, maar zowel Ben als ik krijgen geen alarm......
Ik durf het bijna niet te vragen, maar... hebben jullie dat getest??

Ja, het hele project is een week lang getest door veschillende medewerkers. En het alarm werkte daarbij ook. Wel is het zo dat we ALLEEN gestest hebben met een gesorteerde lijst en NIET met een ongesorteerde lijst... Misschien is dat het probleem?

Nee, nee, we zitten niet stil . nadat het eerst niet werkte met de ongesorteerde lijst heb ik een gesorteerde lijst genomen. Maar dat werkte evenmin. Nu heb ik in de flowcode een verhaal gevonden waarin staat dat in "de nieuwe versie" transfert.exe de data tijdens het laden al omrekent in een ander format.
Kan het zijn dat wij de oude flowcode hebben en de nieuwe transfert.exe of andersom??

[thijsbeckers]

Nadat het eerst niet werkte met de ongesorteerde lijst heb ik een gesorteerde lijst genomen. Maar dat werkte evenmin. Nu heb ik in de flowcode een verhaal gevonden waarin staat dat in "de nieuwe versie" transfert.exe de data tijdens het laden al omrekent in een ander format.
Kan het zijn dat wij de oude flowcode hebben en de nieuwe transfert.exe of andersom??

Volgens mij staat de correcte versie van transfert.exe bij ons op de site, samen met de correcte versie van de broncode (flowcode). Of bedoel je het programma Flowcode (v3)?

[jaap57]

Nadat het eerst niet werkte met de ongesorteerde lijst heb ik een gesorteerde lijst genomen. Maar dat werkte evenmin. Nu heb ik in de flowcode een verhaal gevonden waarin staat dat in "de nieuwe versie" transfert.exe de data tijdens het laden al omrekent in een ander format.
Kan het zijn dat wij de oude flowcode hebben en de nieuwe transfert.exe of andersom??

Volgens mij staat de correcte versie van transfert.exe bij ons op de site, samen met de correcte versie van de broncode (flowcode).

Als dat waar is dan moet het ergens anders in zitten want ik gebruik die files van jullie site....

Nog een opmerking over iets heel anders: Na het bouwen van de hardware bleek het LCD niet te werken. Dit bleek te zitten in het feit dat de initialisatie van het dislay begon voordat het display was opgestart. Door een delay van een paarhonderd miliseconden in het programma op te nemen direct na de start werd dit probleem verholpen.

[thijsbeckers]

Na het bouwen van de hardware bleek het LCD niet te werken. Dit bleek te zitten in het feit dat de initialisatie van het dislay begon voordat het display was opgestart. Door een delay van een paarhonderd miliseconden in het programma op te nemen direct na de start werd dit probleem verholpen.

Misschien heeft dit te maken met dat je iets andere onderdelen gebruikt (bv een MAX232 ipv een FT232)?
Ben, had jij dit probleem ook?

[jaap57]

Na het bouwen van de hardware bleek het LCD niet te werken. Dit bleek te zitten in het feit dat de initialisatie van het dislay begon voordat het display was opgestart. Door een delay van een paarhonderd miliseconden in het programma op te nemen direct na de start werd dit probleem verholpen.

Misschien heeft dit te maken met dat je iets andere onderdelen gebruikt (bv een MAX232 ipv een FT232)?
Ben, had jij dit probleem ook?

Nee,nee, want dat gedeelte zat er bij mij nog niet in!
Die communicatie-IC's worden niet gebruikt als het daarvoor bedoelde schakelaartje open staat. Nee het gaat hier waarschijnlijk om het display dat ik gebruik. Net ietsje langzamer dan dat wat jullie of die Fransen gebruikten..
Na het inschakelen van de spanning was het programma al op reis terwijl mijn display z'n koffers nog stond te pakken

[schueler]

Ben, had jij dit probleem ook?

Nee, ik had dit probleem niet. Ik heb meerdere type LCD's erop aangesloten gehad en werkte alle naar behoren. Een langere reset tijd zou ook kunnen helpen. Dan heeft het LCD scherm ook langer de tijd om intern alles op orde te brengen.

Ik ben nu bezig om de waardes die gelezen worden tijdens het checken van het coördinaat op het display te zetten. Het nadeel is dan steeds weer dat ik eerst andere dingen moet weggooien om de debug info eruit te krijgen.

Na het nog eens bekijken van de van het schema viel me op dat de TxD pin van de PIC altijd aangesloten is aan de UART.
Dit kan voor debug doeleinde gebruikt worden en volgens mij wordt dit al gedaan wat ik zo in de software af en toe zie.


Ben

[thijsbeckers]

Ik heb van het weekend het prototype meegenomen, via de op de site geplaatste versie van transfert.exe gevuld met zo'n 16.000 'points of interest' (gedownload van de site die bij de updates op de pagina van het project vermeld staat).

Werkte prima. Tussen Sittard en Tilburg een stuk of 4 meldingen gekregen. En de snelheidsaanduiding is ook erg handig om de cruise control af te stellen .

Het project zou dus zeker aan de praat te krijgen moeten zijn. We hebben ook al redelijk wat geprogrammeerde controllers verkocht en hiermee verder geen problemen gehoord. Misschien is ergens een programmeerinstelling niet helemaal goed?

[schueler]

Bedankt voor de info en tijd die je erin hebt gestoken Thijs.
Ik heb het dus nog niet aan de praat gekregen en ben begonnen met de software onder de loep te nemen.
Momenteel spuugt het debug informatie naar buiten over de gelezen punten uit de I2C EEprom. Dit lijkt allemaal te kloppen.
Echter als ik de flitspaal file laad en het uitprobeer bij de "bekende" palen bij mij in de buurt gebuurd er niets....

Zit er steeds meer aan te denken om de code te herschrijven ( als ik even wat meer tijd heb ). Volgens mij kan het korter en worden er variabelen veelvuldig dubbel geschreven terwijl dit maar enkel hoeft.

Ben