Communicatie tussen Arduino Uno en atoomkloksignaal ontvanger/decodeer module

Hallo

Ik heb een FUM DCF-U module (Ontvanger-decodeer module voor het atoomkloksignaal)gekocht van HKW-electronik. Het probleem is dat ze enkel een Duitstalige documentatie hebben hierover (zie bijlage). De vertaalrobots doen niet echt goed hun werk als het gaat om technische vertalingen. Ik heb ze bij HKW-elektronik gevraagd of er een Engelstalige versie bestaat maar kreeg geen antwoord. Ook een vertaling kost me te veel geld.

Mijn vraag is of iemand mij de essentie kan vertellen in het Nederlands of Engels zodat ik weet hoe ik met deze module moet communiceren zodat ik bruikbare data kan verkrijgen?

Het aansluiten van de hardware is geen enkel probleem maar wel het software gedeelte i.v.m. de communicatie tussen een Arduino Uno en de module. Dus kortom een duidelijke theoretische uitleg over hoe de communicatie verloopt, tussen de Arduino en de module, waarop ik mijn code kan baseren.

Jullie zijn alvast bedankt.

Al eens met "translate.google.nl" vertaald ?
Anders een PM naar mij.
MVG Gerard.;)

Beste Gerard

Ik heb dit reeds geprobeerd maar zonder begrijpbaar resultaat, althans voor mij. Ik krijg de vertaalde stukken tekst niet in een fatsoenlijk begrijpbare tekst geplaatst.

Toch bedankt voor de moeite

Geef even aan waar je problemen hebt. Dan vertalen we dat deel. heel de PDF vertalen gaat me wat te ver.

Even kort:

Communicatie naar de module toe 300Bd (bits/seconde), 8 bits, geen pariteit, 2 stopbits.

Antwoord van de module 300Bd (bits/seconde), 7 bits, even pariteit, 2 stopbits.

Beide zijn al niet heel standaard en vrij traag. 4800Bd, 8 bits, even (of geen) pariteit en 1 stopbit is meer gangbaar.

De module geeft elk ontvangen teken als echo terug als controle.

Veel micro's ondersteunen geen 2 stopbits of 7 bits data. In zo'n geval moet je wat tweaken, of een software uart gebruiken...

Alle ATmega die ik ken ondersteunen perfect 7 bits en 2 stopbits.

Uit de datasheet van de ATmega48/88/168:


19.4 Frame Formats
A serial frame is defined to be one character of data bits with synchronization bits (start and stop
bits), and optionally a parity bit for error checking. The USART accepts all 30 combinations of
the following as valid frame formats:
   - 1 start bit
   - 5, 6, 7, 8, or 9 data bits
   - no, even or odd parity bit
   - 1 or 2 stop bits

ATtiny2313 geeft dezelfde specs.

Vermits een Arduino een ATmega is, zijn er dus geen problemen te verwachten wat dat betreft.

Simple protocol.
Inderdaad 300 baud, 8 databits, geen parity, 2 Stop bits.

Host moet per byte commando sturen, en telkens wachten op de echo van het verstuurde byte.
Daarna minimaal nog 5 milliseconden wachten en dan pas het volgende byte versturen.

[Edit]
Alle data van de module gebruikt bit7 als parity bit. Die kun je dus beter wegfilteren (Data & 0x7F)
[/Edit]
Module gaat niet zelf iets opsturen, maar reageert wel op commando's.

Belangrijkste commando's:


=================================================
Opvragen tijd:
-- 2 bytes : 0x3F 0x0D  ( "?<CR>"
-- Eerste byte mag ook 0x4F of 0x6F zijn, als het maar op 0x-F eindigt. 

Antwoord:
-- 15 Bytes + <CR>:
   HHMMSSWDDMMYYPS<CR>

   HHMMSS : Uren minuten Seconden, telkens 2 cijfers
   W      : Dag vd week. 1 (= Maandag) ..7 (= zondag)
   DDMMYY : Dag, Maand Jaar
   PS     : Protocol en Status Byte.
            Protocol Byte :
              Bit 2,1 
              -----10- = Wintertijd
              -----01- = Zomertijd
              Bit 0 
              -------1 = Aankondiging omschakelen Winter/Zomertijd
            Status Byte:
              Bit 3
              ----1--- = Batterijspanning te laag
              Bit 2
              -----1-- = Laatste Ontvangst mislukt
              Bit 1
              ------1- = Laatste ontvangst successvol
              Bit 0
              -------1 = Tijd is geldig.

PS:
  Antwoord kan even uitblijven want gaat synchroon met verspringen van Seconde.             


=================================================
Opvragen wereld-tijd

-- 2 bytes : 0x45 0x0D   ( "e<CR>" )
-- Eerste byte mag ook 0x35 of 0x65 zijn, als het maar op 0x-5 eindigt. 

Antwoord: 
-- Hetzelfde format als bij opvragen tijd.


=================================================
Opvragen mode

-- 2 bytes : 0x46 0x0D  ( "f<CR>" )
-- Eerste byte mag ook 0x36 of 0x66 zijn, als het maar op 0x-6 eindigt. 

Antwoord: 
-- 4 bytes +<CR>.
   HHS0
   HH = Uren sinds laatste synchronisatie van de tijd.
   S  = Status
        Bit 3 :
        ----1--- = DCF77
        ----0--- = MSF
   0  = Altijd '0'      
 
   (Volgens mij is MSF een engelse zender en geeft dus ook engelse tijd)


=================================================
Ontvanger inschakelen en tijd Synchroniseren.

-- 2 bytes : 0x48 0x0D     ( "h<CR>" )
-- Eerste byte mag ook 0x38 of 0x68 zijn, als het maar op 0x-8 eindigt. 

Geen antwoord. 
Tijd kan worden opgevraagd met andere commando's.
Status bit blijft 0 zolang geen tijd ontvangen is.

Hallo

Ik begrijp dat het niet mogelijk is om jullie te vragen om een volledige handleiding te vertalen ;)

Ik heb al veel bruikbare antwoorden gelezen, mijn dank hiervoor.
De problemen die nog resten zijn:
- Moet ik de ingang van de module op een bepaalde module aansturen om de data te ontvangen of stuurt deze dat continu door.
- Stuurt de module de data voor elke seconde door of alles in één keer?

Ik denk dat dit in hoofdstuk 3 staat en misschien wat specifieker in 3.2.4. Maar ben daar niet geheel zeker van omdat ik niet veel Duits kan.

Jullie zijn al heel fel bedankt

[Bericht gewijzigd door vayneless op (14%)]

X3 (RS232 IN) laag houden zorgt er voor dat er elke volle seconde een nieuwe tijdstring wordt verzonden. Gedurende 600ms stijgt dan het verbruik van de klok naar 200µA.

Datasheet

edit: De klok is slechts 3V. Er wordt van RS232 gesproken, dat zou betekenen dat er -12V en +12V als spanningen worden gebruikt. De uitgang (X4) geeft slechts 3V uit. Ik denk dat je er moet van uitgaan dat de X4 een spanning tussen 0V en 3V nodig heeft. Wil je constant een string ontvangen, knoop dan X4 gewoon vast aan GND. Anders er op letten dat er geen 5V op de ingang komt. Ofwel de arduino op 3v, als dat kan, of de 5V terug brengen naar 3V. Eventueel met een HEF4050, 74LVX245 of 74AHC125.

[Bericht gewijzigd door buckfast_beekeeper op (50%)]

Als je continu laat sturen dan wordt batterij voeding onhandig.
Wat wordt de afstand tussen module en de controller/processor?
Dit i.v.m. signaal niveaus, drivers, etc..

RS232 levels mogen +3 tot +25 en -3 tot -25 volt zijn. Dat +/-12 V veel voorkomt heeft met beschikbare voedingsrails te maken.

Aan zender zijde is het minimaal 5V. Daar voldoet de module niet aan. Als je een negatieve spanning aanbied zie ik het ook niet goed komen. Mogelijk overleven ze 5V op de ingang maar het staat alleszins niet vermeld. Wat dat betreft zou ik het zekere voor het onzekere nemen.

Handigste naar communicatie toe is 2 aparte uart, 1 op 300Bd, 7 bits, even pariteit en 2 stopbits om te ontvangen en de andere op 300Bd, 8 bits, geen pariteit en 2 stopbits om te zenden.

Als je niet elke seconde een string opvraagt, zal je zelf de seconden moeten tellen. Voordeel is wel dat je via de communicatie kan opvragen wanneer de laatste correcte ontvangst gebeurde.

Wat ik niet uit de handleiding haal, of ik kijk er over, welke tijd wordt er weergegeven? DCF loopt 1 minuut voor. Je ontvangt steeds de gegevens van de volgende minuut. Wordt hier de tot de seconde nauwkeurige realtime uitgezonden?

Beste

Ik heb enkel de uren en minuten nodig van het signaal.
Ik gebruik een max232 voor de omzetting van RS232 naar uart, dit omwille van ik alles wil omzetten naar een atmega32 (geen Arduino). De Arduino dient enkel als prototype.

De max232 heeft enkel zijn voedingsspanningen van 3 en 5V.

Ik ga met de bovenstaande info de communicatie proberen te laten werken deze week. Jullie mogen altijd bijkomende info posten en ik laat jullie de resultaten weten.

Als de ontvangstmodule op korte afstand van de atmega zit dan hoeft er geen max232 gebruikt te worden.

Dus voor korte afstanden moet ik geen max232 chip gebruiken voor conversie? Want de atmega32 heeft geen RS232, enkel UART.

De datasheet noemt het RS-232, maar dat is het niet. Uitgang is gewoon TTL (0 en 3.3 volt)

De DCF module geeft ook geen rs-232 signaalniveaus.
Min of meer TTL.

Inderdaad iets afwijkend. TTL levels zijn 0.8/2.0 volt, module is 0.6/2.5 volt...

Lees dit eens door, misschien kan je er nog iets uithalen. Dit gaat wel over pic controllers, maar het principe is het zelfde. op deze manier doe ik de communicatie tussen PC en pic.

Van blz. 52 tot blz. 95 staan voorbeelden.
http://www.circuitsonline.net/artikelen/view/46

Op 21 maart 2016 14:36:03 schreef vayneless:
Beste

Ik heb enkel de uren en minuten nodig van het signaal.
Ik gebruik een max232 voor de omzetting van RS232 naar uart, dit omwille van ik alles wil omzetten naar een atmega32 (geen Arduino). De Arduino dient enkel als prototype.

Zoals gezegd is de max232 niet nodig. Persoonlijk zou ik eerder richting een Avr met 2 uart gaan. Bijvoorbeeld een ATmega324. Als je deze gebruikt op 5V zou ik toch overwegen de ingang van de klok te beschermen.

Ik zou dan ook maar om de minuut de tijd opvragen en aanpassen. Een timer eerst synchroniseren met een volle minuut, na iets meer dan 59 seconden terug de tijd vragen en terug synchroniseren.

Die atmega zal toch ook wel op 3.3 volt kunnen werken? Iedere moderne controller kan dat bijna. (5 volt begint steeds meer een uitzondering te worden...)

Kan inderdaad maar dan max op 10MHz. Boven 10MHz tussen 4,5 en 5,5V.

Ook al zouden ontvanger en atmega op dezelfde spanning werken, zolang het 2 losse printen zijn zou ik beveiliging toepassen.

Hey

Ik heb een klein programma geschreven, in python, voor het uitlezen van de module als prototype.

Ik krijg in de seriële monitor het volgende:
üp|üp|þp~üp|üp|üp|üp|üp|þp~üp|üp|üp|üp|þp~üp|üp|üp|üp|üp|þp~þp~üp|üp|üp|þp~þp~üp|üp|üp|þp~þp~þp~üp|üp|üp|üp|þp~üp|üp|üp|üp|þp~üp|üp|üp|üp|
.....

Wat moet ik hieruit opmaken en wat zou ik fout doen?

Code:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // RX, TX

void setup()  
{
  // Open serial communications and wait for port to open:
  Serial.begin(300);

  // Set the data rate for the SoftwareSerial port
  mySerial.begin(300);
  
// Wait for synchronisation with the signal
  delay(180000);
}

void loop() // run over and over
{
  // Send time protocol command
  Serial.write(0x3F);
  Serial.write(0x0D);
  
  // Display signal
  if (Serial.available())
    mySerial.println(char (Serial.read()));
  
  // Wait a minute
  delay(60000);
}

Op 22 maart 2016 20:54:01 schreef vayneless:
Hey

Ik heb een klein programma geschreven, in python, voor het uitlezen van de module als prototype.

Ik krijg in de seriële monitor het volgende:
üp|üp|þp~üp|üp|üp|üp|üp|þp~üp|üp|üp|üp|þp~üp|üp|üp|üp|üp|þp~þp~üp|üp|üp|þp~þp~üp|üp|üp|þp~þp~þp~üp|üp|üp|üp|þp~üp|üp|üp|üp|þp~üp|üp|üp|üp|
.....

Wat moet ik hieruit opmaken en wat zou ik fout doen?

Aansluiting:
Module | Arduino
X1 | 3V (van de Arduino)
X2 | GND (van de Arduino)
X3 | 11 (digitale pin)
X4 | 10 (digitale pin)
X5 | Antenne
X6 | Antenne

Code:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // RX, TX

void setup()  
{
  // Open serial communications and wait for port to open:
  Serial.begin(300);

  // Set the data rate for the SoftwareSerial port
  mySerial.begin(300);
  
// Wait for synchronisation with the signal
  delay(180000);
}

void loop() // run over and over
{
  // Send time protocol command
  Serial.write(0x3F);
  Serial.write(0x0D);
  
  // Display signal
  if (Serial.available())
    mySerial.println(char (Serial.read()));
  
  // Wait a minute
  delay(60000);
}