elektroda.net NewsGroups Forum Index - Electronics BE - PICs en draadloze verbindingen
Martijn van Buul
Guest
Guest
Thu Sep 11, 2008 12:27 pm
Nico Coesel (nico_at_puntnl.niks) schreef:
Quote:
Martijn van Buul <pino_at_dohd.org> wrote:
Nico Coesel (nico_at_puntnl.niks) schreef:
[ grote knip ]
Tot hier was ik het roerend met je eens, maar:
Als je begint met een platform waarop je goed in C kunt programmeren (dus
niet de PIC, 8051 of AVR),
Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin
ook, maar die wil je om andere redenen niet meer.
Maak eens een programma waarin je met strcpy en strcat een constante
en niet constante character array naar een niet constant character
array wilt kopieren. Dat gaat niet op een harvard architectuur zonder
bijzondere (trage) pointer acrobatiek omdat de processor aan de
pointer zelf niet kan zien in welke geheugen de data moet worden
opgehaald/weggeschreven.
Nico Coesel (nico_at_puntnl.niks) schreef:
[ grote knip ]
Tot hier was ik het roerend met je eens, maar:
Als je begint met een platform waarop je goed in C kunt programmeren (dus
niet de PIC, 8051 of AVR),
Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin
ook, maar die wil je om andere redenen niet meer.
Maak eens een programma waarin je met strcpy en strcat een constante
en niet constante character array naar een niet constant character
array wilt kopieren. Dat gaat niet op een harvard architectuur zonder
bijzondere (trage) pointer acrobatiek omdat de processor aan de
pointer zelf niet kan zien in welke geheugen de data moet worden
opgehaald/weggeschreven.
So? Het is wat minder handig, inderdaad, maar
*juist omdat je in C programmeert* heb je er helemaal geen last van, omdat
de compiler dit soort details voor je oplost.
Je ondergraaft je eigen stelling. Je wil juist een taal als C gebruiken
om allerlei details over je processor te verbergen. Of wou je beweren dat
MIPS lekker fijn in assembly programmeert?
Quote:
[knip]
En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H
uitstekende GCC compilers beschikbaar voor niets.
Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
platform (waaronder AVR, overigens) is geen reden om andere beschikbare
C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
CodeVision AVR voor de AVR) te negeren.
Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de
8051 nog eens zo krom is als een hoepel (been there, done that).
En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H
uitstekende GCC compilers beschikbaar voor niets.
Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
platform (waaronder AVR, overigens) is geen reden om andere beschikbare
C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
CodeVision AVR voor de AVR) te negeren.
Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de
8051 nog eens zo krom is als een hoepel (been there, done that).
Ik pak de 2 platformen die jij eerder al aan de kant had geschoven omdat je
ze niet in C zou kunnen programmeren. Wat baarlijke onzin is.
En geloof me, ik ken de 8051. Heb jarenlang op de 8-bit microcontroller
sales support van een bepaalde voormalige gloeilampenfabrikant in het
zuiden des lands gewerkt. Je mag drie keer raden welke CPU.
Quote:
Maar voor 32 bit platforms presteert de GCC compiler zeer goed.
*proest*.
Quote:
Gcc is *zo* brak, dat een alle-remmen-los release build van gcc, met maximale
optimalisaties, vaak *langzamer* is dan een debug build van msvc. Om maar
eens een zijstraat te noemen. En dat is dan op een mainstream platform als
32-bits x86.
Dat lijkt me erg sterk. Dit soort stellingen komen meestal van mensen
die van de ene compiler wel goed weten hoe die werkt en van de andere
compiler totaal niet.
optimalisaties, vaak *langzamer* is dan een debug build van msvc. Om maar
eens een zijstraat te noemen. En dat is dan op een mainstream platform als
32-bits x86.
Dat lijkt me erg sterk. Dit soort stellingen komen meestal van mensen
die van de ene compiler wel goed weten hoe die werkt en van de andere
compiler totaal niet.
En toch zie ik het keer op keer. Inmiddels weet ik hoe ik mijn C zo moet
schrijven dat zelfs het stomste kindje uit de klas (Wist je overigens dat
GCC een afkorting is? Staat voor GCC Can't Compile) het een beetje snapt.
En zelfs dan. GCC is stom. En het ergste is nog dat het er van uitgaat
dat ik *OOK* stom ben.
Quote:
1 ding weet ik zeker: er zit veel meer tijd en energie in GCC dan in iedere
andere compiler.
andere compiler.
Veel meer tijd ja - waaronder heel veel verprutste tijd. Tijd verprutst aan
het toevoegen van zinloze warnings omdat er zoetwaterprogrammeurs zijn die
te stom zijn om te weten dat && boven || gaat.
Quote:
Als GCC veel slechter presteert dan een commerciele compiler dan doe je of
iets heel erg fout of je hebt heel erg veel geld betaald voor de commerciele
compiler.
iets heel erg fout of je hebt heel erg veel geld betaald voor de commerciele
compiler.
Of de commerciele compiler is voor een specifieke architectuur geschreven, ipv
voor zoveel mogelijk achitecturen tegelijkertijd.
Intel's icc bestaat niet voor niets, bijvoorbeeld.
Als je dat fundamentele verschil weigert te accepteren, vraag ik me af wie
er nou degene is die oogkleppen op heeft.
Maar weet je wat de belangrijkste reden is waarom OP misschien beter af is met
een simpele AVR? Heeft helemaal niets met architecturen, C-compilers of wat
dan ook te maken, maar met een hele simpele reden:
Een Atmel AVR komt in een fijne DIL behuizing, en is gemakkelijk op een stuk
gaatjesbord te solderen. Kom daar maar eens mee, met je 48 pins LQFP "low pin
count" ARM. Of MIPS. Of H8. Zeker zo vriendelijk voor een hobbyist.
--
Martijn van Buul - pino_at_dohd.org
Rob
Guest
Guest
Thu Sep 11, 2008 3:59 pm
wimpunk <bkcfscpmcuin_at_spammotel.com> wrote:
Quote:
Ik zou je aanraden om die DCF-77 ontvanger te vervangen door een RDS of
een GPS ontvanger. Uit ervaring weet ik dat die een stuk beter
ontvangst hebben tegenwoordig dan DCF.
een GPS ontvanger. Uit ervaring weet ik dat die een stuk beter
ontvangst hebben tegenwoordig dan DCF.
Dat kun je niet 1:1 vergelijken. DCF is erg gevoeling voor storingen
van monitoren en tl-buizen, maar het signaal dringt wel behoorlijk goed
door in gebouwen. Dat kun je van GPS niet zeggen: voor een fatsoenlijke
GPS ontvangst heb je vrij zicht naar boven nodig. In een gebouw waar
niet te veel storing is kan DCF best beter werken dan GPS.
RDS heb ik geen ervaring mee als tijdstandaard. Je bent afhankelijk van
het kwaliteitsbesef van de technici van de zender, vrees ik.
Nico Coesel
Guest
Guest
Thu Sep 11, 2008 5:35 pm
Martijn van Buul <pino_at_dohd.org> wrote:
Quote:
Nico Coesel (nico_at_puntnl.niks) schreef:
Martijn van Buul <pino_at_dohd.org> wrote:
Nico Coesel (nico_at_puntnl.niks) schreef:
[ grote knip ]
Tot hier was ik het roerend met je eens, maar:
Als je begint met een platform waarop je goed in C kunt programmeren (dus
niet de PIC, 8051 of AVR),
Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin
ook, maar die wil je om andere redenen niet meer.
Maak eens een programma waarin je met strcpy en strcat een constante
en niet constante character array naar een niet constant character
array wilt kopieren. Dat gaat niet op een harvard architectuur zonder
bijzondere (trage) pointer acrobatiek omdat de processor aan de
pointer zelf niet kan zien in welke geheugen de data moet worden
opgehaald/weggeschreven.
So? Het is wat minder handig, inderdaad, maar
*juist omdat je in C programmeert* heb je er helemaal geen last van, omdat
de compiler dit soort details voor je oplost.
Martijn van Buul <pino_at_dohd.org> wrote:
Nico Coesel (nico_at_puntnl.niks) schreef:
[ grote knip ]
Tot hier was ik het roerend met je eens, maar:
Als je begint met een platform waarop je goed in C kunt programmeren (dus
niet de PIC, 8051 of AVR),
Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin
ook, maar die wil je om andere redenen niet meer.
Maak eens een programma waarin je met strcpy en strcat een constante
en niet constante character array naar een niet constant character
array wilt kopieren. Dat gaat niet op een harvard architectuur zonder
bijzondere (trage) pointer acrobatiek omdat de processor aan de
pointer zelf niet kan zien in welke geheugen de data moet worden
opgehaald/weggeschreven.
So? Het is wat minder handig, inderdaad, maar
*juist omdat je in C programmeert* heb je er helemaal geen last van, omdat
de compiler dit soort details voor je oplost.
Maar wel ten koste van performance en tegenwoordig koop je voor
hetzelfde geld een veel snellere en betere microcontroller die al die
truukerij niet nodig heeft. Waarom zou je nog met paard en wagen op
weg gaan als je voor hetzelfde of minder geld een auto hebt?
Quote:
[knip]
En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H
uitstekende GCC compilers beschikbaar voor niets.
Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
platform (waaronder AVR, overigens) is geen reden om andere beschikbare
C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
CodeVision AVR voor de AVR) te negeren.
Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de
8051 nog eens zo krom is als een hoepel (been there, done that).
Ik pak de 2 platformen die jij eerder al aan de kant had geschoven omdat je
ze niet in C zou kunnen programmeren. Wat baarlijke onzin is.
En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H
uitstekende GCC compilers beschikbaar voor niets.
Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
platform (waaronder AVR, overigens) is geen reden om andere beschikbare
C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
CodeVision AVR voor de AVR) te negeren.
Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de
8051 nog eens zo krom is als een hoepel (been there, done that).
Ik pak de 2 platformen die jij eerder al aan de kant had geschoven omdat je
ze niet in C zou kunnen programmeren. Wat baarlijke onzin is.
Het kan wel, maar je doet jezelf tekort en je loopt een keer tegen de
grens aan en dan zeg je 'had ik maar...'. Been there, done that -hier
spreekt ervaring-. Probeer eens functie pointers op een 8051. De Keil
8051 compiler ondersteund dat alleen met constante functie pointers.
En zo zijn er nog wel meer dingen die je als je begint niet kunt
overzien, maar waar je wel flink last kunt krijgen. Vandaar mijn
advies om niet met 8051, PIC of AVR te beginnen ook al lijkt de DIL
behuizing zo aantrekkelijk. Dat zijn valkuilen die je uiteindelijk
flink veel tijd gaan kosten.
Quote:
En geloof me, ik ken de 8051. Heb jarenlang op de 8-bit microcontroller
sales support van een bepaalde voormalige gloeilampenfabrikant in het
zuiden des lands gewerkt. Je mag drie keer raden welke CPU.
sales support van een bepaalde voormalige gloeilampenfabrikant in het
zuiden des lands gewerkt. Je mag drie keer raden welke CPU.
Wie heeft er niet met de 8051 gewerkt, maar wat mij betreft mag het
ding begraven worden.
Quote:
Maar voor 32 bit platforms presteert de GCC compiler zeer goed.
*proest*.
Gcc is *zo* brak, dat een alle-remmen-los release build van gcc, met maximale
optimalisaties, vaak *langzamer* is dan een debug build van msvc. Om maar
eens een zijstraat te noemen. En dat is dan op een mainstream platform als
32-bits x86.
Dat lijkt me erg sterk. Dit soort stellingen komen meestal van mensen
die van de ene compiler wel goed weten hoe die werkt en van de andere
compiler totaal niet.
En toch zie ik het keer op keer. Inmiddels weet ik hoe ik mijn C zo moet
schrijven dat zelfs het stomste kindje uit de klas (Wist je overigens dat
GCC een afkorting is? Staat voor GCC Can't Compile) het een beetje snapt.
*proest*.
Gcc is *zo* brak, dat een alle-remmen-los release build van gcc, met maximale
optimalisaties, vaak *langzamer* is dan een debug build van msvc. Om maar
eens een zijstraat te noemen. En dat is dan op een mainstream platform als
32-bits x86.
Dat lijkt me erg sterk. Dit soort stellingen komen meestal van mensen
die van de ene compiler wel goed weten hoe die werkt en van de andere
compiler totaal niet.
En toch zie ik het keer op keer. Inmiddels weet ik hoe ik mijn C zo moet
schrijven dat zelfs het stomste kindje uit de klas (Wist je overigens dat
GCC een afkorting is? Staat voor GCC Can't Compile) het een beetje snapt.
Ik dacht dat GCC stond voor Gnu compiler collection, maar weer wat
geleerd.
Quote:
En zelfs dan. GCC is stom. En het ergste is nog dat het er van uitgaat
dat ik *OOK* stom ben.
dat ik *OOK* stom ben.
En dat is maar goed ook. Ook de gevorderde programmeur maakt stomme
fouten.
Quote:
1 ding weet ik zeker: er zit veel meer tijd en energie in GCC dan in iedere
andere compiler.
Veel meer tijd ja - waaronder heel veel verprutste tijd. Tijd verprutst aan
het toevoegen van zinloze warnings omdat er zoetwaterprogrammeurs zijn die
te stom zijn om te weten dat && boven || gaat.
andere compiler.
Veel meer tijd ja - waaronder heel veel verprutste tijd. Tijd verprutst aan
het toevoegen van zinloze warnings omdat er zoetwaterprogrammeurs zijn die
te stom zijn om te weten dat && boven || gaat.
Ik noem dat handig want dergelijke programmeurs komen bij bosjes van
school. Programmeer maar lekker simpel want dan kan iemand anders het
project later nog van je overnemen.
Quote:
Als GCC veel slechter presteert dan een commerciele compiler dan doe je of
iets heel erg fout of je hebt heel erg veel geld betaald voor de commerciele
compiler.
Of de commerciele compiler is voor een specifieke architectuur geschreven, ipv
voor zoveel mogelijk achitecturen tegelijkertijd.
iets heel erg fout of je hebt heel erg veel geld betaald voor de commerciele
compiler.
Of de commerciele compiler is voor een specifieke architectuur geschreven, ipv
voor zoveel mogelijk achitecturen tegelijkertijd.
Dan snap je de opzet van GCC niet. Iedere architectuur heeft juist
zijn eigen back-end met specifieke optimalisaties. Een GCC versie
heeft altijd nog wel een dozijn platform specifieke opties. Alleen de
voorkant is hetzelfde. Wel zo prettig als je code wilt porteren van de
ene naar de andere compiler. Dan kom je erachter dat C niet altijd C
is.
Quote:
Intel's icc bestaat niet voor niets, bijvoorbeeld.
Als je dat fundamentele verschil weigert te accepteren, vraag ik me af wie
er nou degene is die oogkleppen op heeft.
Als je dat fundamentele verschil weigert te accepteren, vraag ik me af wie
er nou degene is die oogkleppen op heeft.
Kijk en vergelijk en je ziet dat GCC zich doorgaans in de top van de
compilers voor een bepaalde architectuur bevind.
Quote:
Maar weet je wat de belangrijkste reden is waarom OP misschien beter af is met
een simpele AVR? Heeft helemaal niets met architecturen, C-compilers of wat
dan ook te maken, maar met een hele simpele reden:
Een Atmel AVR komt in een fijne DIL behuizing, en is gemakkelijk op een stuk
gaatjesbord te solderen. Kom daar maar eens mee, met je 48 pins LQFP "low pin
count" ARM. Of MIPS. Of H8. Zeker zo vriendelijk voor een hobbyist.
een simpele AVR? Heeft helemaal niets met architecturen, C-compilers of wat
dan ook te maken, maar met een hele simpele reden:
Een Atmel AVR komt in een fijne DIL behuizing, en is gemakkelijk op een stuk
gaatjesbord te solderen. Kom daar maar eens mee, met je 48 pins LQFP "low pin
count" ARM. Of MIPS. Of H8. Zeker zo vriendelijk voor een hobbyist.
Eitje en je hebt er geeneens speciaal gereedschap voor nodig (hint:
hoe dunner de soldeerbout, hoe lastiger je het voor jezelf maakt).
Flux, een schone punt en desoldeerlitze voor de ongelukjes. Bovendien
zijn er heel veel kant & klare bordjes tekoop die je zo in je project
zet. Kan het nog makkelijker?
--
Programmeren in Almere?
E-mail naar nico_at_nctdevpuntnl (punt=.)
wimpunk
Guest
Guest
Thu Sep 11, 2008 5:45 pm
Rob wrote:
Quote:
wimpunk <bkcfscpmcuin_at_spammotel.com> wrote:
Ik zou je aanraden om die DCF-77 ontvanger te vervangen door een RDS of
een GPS ontvanger. Uit ervaring weet ik dat die een stuk beter
ontvangst hebben tegenwoordig dan DCF.
Dat kun je niet 1:1 vergelijken. DCF is erg gevoeling voor storingen
van monitoren en tl-buizen, maar het signaal dringt wel behoorlijk goed
door in gebouwen. Dat kun je van GPS niet zeggen: voor een fatsoenlijke
GPS ontvangst heb je vrij zicht naar boven nodig. In een gebouw waar
niet te veel storing is kan DCF best beter werken dan GPS.
RDS heb ik geen ervaring mee als tijdstandaard. Je bent afhankelijk van
het kwaliteitsbesef van de technici van de zender, vrees ik.
Ik zou je aanraden om die DCF-77 ontvanger te vervangen door een RDS of
een GPS ontvanger. Uit ervaring weet ik dat die een stuk beter
ontvangst hebben tegenwoordig dan DCF.
Dat kun je niet 1:1 vergelijken. DCF is erg gevoeling voor storingen
van monitoren en tl-buizen, maar het signaal dringt wel behoorlijk goed
door in gebouwen. Dat kun je van GPS niet zeggen: voor een fatsoenlijke
GPS ontvangst heb je vrij zicht naar boven nodig. In een gebouw waar
niet te veel storing is kan DCF best beter werken dan GPS.
RDS heb ik geen ervaring mee als tijdstandaard. Je bent afhankelijk van
het kwaliteitsbesef van de technici van de zender, vrees ik.
Dat klopt maar aangezien OP toch van plan was om de DCF aan de andere
kant van zijn tuin te hangen leken ze me beide wel mogelijk.
Wij merken trouwens op dat in computerruimtes waar vroeger de DCF
ontvangst goed was de laatste jaren het ontvangst erop achteruit is
gegaan... Een gevolg van meer storingen? In nieuwe installaties kiezen
we er dan ook altijd voor om de internet tijd te gebruiken.
Moi
Guest
Guest
Thu Sep 11, 2008 5:56 pm
On Mon, 08 Sep 2008 22:27:48 +0200, Kristoff Bonne wrote:
Quote:
Aan allen die zijn of zullen zijn, gegroet,
- Ik heb hier nog een ontvangst-toestelletjes liggen die signalen van
DCF-77 kan ontvangen en doorgeven aan een computer via de RS232 poort.
Maar door problemen met interferentie heeft die nooit echt goed gewerkt.
Het zou misschien interessant zijn om daarvoor een PIC of single-chip
processor te gebruiken, zodat ik die dan ver achteraan in de tuin kan
leggen, ver weg van alle bronnen van interferentie in het huis. En dan
de tijdsinformatie via draadloos door-te-sturen naar binnen.
Wat is de beste oplossing om tijd-specifieke informatie draadloos te
versturen?
Kun je een 433 Mhz zendertje ook "pulsen" laten uitsturen (bv. net bij
het begin van een minuut) of enkel "seriele bitpatronen"?
Ik weet het, veel vragen in één keer; maar ik ben dus 15 jaar
"weggeweest". Ik moet dus nogal veel terug "inhalen". :-)
- Ik heb hier nog een ontvangst-toestelletjes liggen die signalen van
DCF-77 kan ontvangen en doorgeven aan een computer via de RS232 poort.
Maar door problemen met interferentie heeft die nooit echt goed gewerkt.
Het zou misschien interessant zijn om daarvoor een PIC of single-chip
processor te gebruiken, zodat ik die dan ver achteraan in de tuin kan
leggen, ver weg van alle bronnen van interferentie in het huis. En dan
de tijdsinformatie via draadloos door-te-sturen naar binnen.
Wat is de beste oplossing om tijd-specifieke informatie draadloos te
versturen?
Kun je een 433 Mhz zendertje ook "pulsen" laten uitsturen (bv. net bij
het begin van een minuut) of enkel "seriele bitpatronen"?
Ik weet het, veel vragen in één keer; maar ik ben dus 15 jaar
"weggeweest". Ik moet dus nogal veel terug "inhalen". :-)
Die 77 KHz onvangertjes zijn nogal gevoelig voor storingen.
Lichtdimmers, wasmachines, stofzuigers, induktiekookplaten, alles.
- Die RS232-kabel kan je makkelijk verlengen tot 20 M of zo; hou hem in
ieder geval weg bij alles waarvan je *weet* dat het stoort (CRT, dimmers)
- ik heb de mijne afgechermd met _zilverpapier_. (Hij is nogal hoog-ohmig)
- een ferrietkraal rond de kabel.
- de software is vaak nogal recht door zee: als er per 1-minuut cyclus
*een* puls teveel of teweinig wordt gedetekteerd, wordt de hele minuut
verworpen.
Hier (Utrecht) werkt een simpele DCF ontvanger prima. (10-20 brakke
minuten per etmaal, voor NTP maakt dat weinig uit, hij sloft toch wel door)
HTH,
AvK
Kristoff Bonne
Guest
Guest
Sun Sep 14, 2008 6:31 pm
Wim,
wimpunk schreef:
Quote:
- Ik heb hier nog een ontvangst-toestelletjes liggen die signalen van
DCF-77 kan ontvangen en doorgeven aan een computer via de RS232 poort.
Maar door problemen met interferentie heeft die nooit echt goed gewerkt.
Het zou misschien interessant zijn om daarvoor een PIC of single-chip
processor te gebruiken, zodat ik die dan ver achteraan in de tuin kan
leggen, ver weg van alle bronnen van interferentie in het huis.
En dan de tijdsinformatie via draadloos door-te-sturen naar binnen.
Wat is de beste oplossing om tijd-specifieke informatie draadloos te
versturen?
Kun je een 433 Mhz zendertje ook "pulsen" laten uitsturen (bv. net bij
het begin van een minuut) of enkel "seriele bitpatronen"?
Ik zou je aanraden om die DCF-77 ontvanger te vervangen door een RDS of
een GPS ontvanger. Uit ervaring weet ik dat die een stuk beter
ontvangst hebben tegenwoordig dan DCF.
DCF-77 kan ontvangen en doorgeven aan een computer via de RS232 poort.
Maar door problemen met interferentie heeft die nooit echt goed gewerkt.
Het zou misschien interessant zijn om daarvoor een PIC of single-chip
processor te gebruiken, zodat ik die dan ver achteraan in de tuin kan
leggen, ver weg van alle bronnen van interferentie in het huis.
En dan de tijdsinformatie via draadloos door-te-sturen naar binnen.
Wat is de beste oplossing om tijd-specifieke informatie draadloos te
versturen?
Kun je een 433 Mhz zendertje ook "pulsen" laten uitsturen (bv. net bij
het begin van een minuut) of enkel "seriele bitpatronen"?
Ik zou je aanraden om die DCF-77 ontvanger te vervangen door een RDS of
een GPS ontvanger. Uit ervaring weet ik dat die een stuk beter
ontvangst hebben tegenwoordig dan DCF.
Dat weet ik, maar dat is nu ook niet echt het probleem.
Voor mij is het meer te doen om het project zelf van nog eens iets te
maken, dan het echt "gebruik". Uiteindelijk, met NTP kun je
vandaag-de-dag toch gewoon syncroniseren over het net.
Ik heb nu éénmaal gewoon het ding liggen, dus ik wil het nu eens gebruiken.
Ik kan het inderdaad ook gewoon aan een PC aansluiten (via de seriele
poort), met een lange seriele kabel om het weg te houden van de
storingsbronnen en -mits een speciale patch op de source van NTP- kan ik
het zelf gebruiken als referentie voor mijn computer als stratum 0 clock.
Maar dat is nu éénmaal niet zo leuk.
Het is een toestelletje waar dat je eigenlijk gewoon de pulsen vanuit de
DCF-zender omzet naar een signaal-niveau op een lijn (die normaal
aangesloten wordt op de seriele poort van de computer). Dus het is iets
waar dat ik zelf de timing moet voor voorzien, zelf de DCF-77 codes
decoderen, dan op één of andere manier de tijd "naar buiten krijgen",
liefst op een manier die gemakkelijk uit-te-lezen is door een computer
(liefst over het internet), zodat die dan als referentie kan dienen voor
een NTP-server.
Waar ik aan denk. Kan men niet gewoon de ruwe signalen die de module
ontvangt overbrengen naar een 433 Mhz zendertje, dus pulsen van 100 of
200 ms uitzenden op 433 Mhz. Dat is dan heel gemakkelijk te ontvangen op
een 10-tal meter afstand en dan zo terug de seriele poort van een
computer in-te-sturen.
En 433 Mhz UHF zal veel minder gestoord worden dan 77 Khz LW!
Cheerio! Kr. Bonne.
elektroda.net NewsGroups Forum Index - Electronics BE - PICs en draadloze verbindingen
