Svenska ElektronikForumet

Men är det totala antalet pulser sedan sändaren startade eg intressant? Kanske bara låta det vara, eller varför vill man ha det?
Och varför decimaler, räkna halva pulser?

Decimaler blir det ju rätt snabbt, t.ex. 125 pulser / 1000 imp./kWh = 0,125 som nu blir 0 kWh.
l och för sig räknar man väl ut totalen för önskad period utifrån momentantvärdena i mjukvaran som samlar in datan...

@carpelux: Snyggt spottat med REG_RXTIMEOUT2 i databladet! Jag har aldrig lekt med RFM868HW-serien, men det står på att göra listan

Jag såg precis som du såg att frekvensen ligger lite under 868MHz. I mitt fall med ca -9 kHz: https://github.com/kodarn/Sparsnas

Ja precis. Totalvärden och annan statistik tycker jag sköts bäst hos mottagaren. En sån här gateway borde bara skicka momentan relevant data.

carpelux skrev:

RegRxTimeout2 (0x2B) interrupt is generated TimeoutRssiThresh *16*T bit after Rssi interrupt if PayloadReady interrupt doesn’t occur.

RegRxTimeout2 är default 0x00, så det kan inte vara lösningen.

Kan man lita på det då? Good practice är ju att aldrig lita på default-inställningar.

@sommarlov: ja det är ju defaultvärde men faktum är att jag fick en massa interrupts som upphörde när jag satte värdet explicit.

carpelux skrev:@sommarlov: ja det är ju defaultvärde men faktum är att jag fick en massa interrupts som upphörde när jag satte värdet explicit.

Jag provade det själv, ingen förändring för mig. Du pratade CW och HW versioner, är detta kanske för CW?

Nej, det är för RFM96HW.

Innan jag satte värdet explicit fick jag många interrupt på DIO0 (payloadready) helt utan korrelation till vad som fanns i etern. Efter det jag satte registret explicit så blev det mycket bättre.

Tog en kik till på total.
Seq ska alltså vara antal 15-sekunders perioder sedan nånting. För tillfället visar min "7774". 7774*15=116610s.
116610/3600 = 32.39h. Och sändaren har varit igång sedan före jul, så det handlar inte om sändarens upptid. Är det ett kontrollvärde för datalagring i mottagaren på nått vis?

Blir lite nyfiken, även om jag är inne på att bara ignorera detta värde.

Jag tror att det är sändarens "upptid", men att det räkneverket slår runt efter ett tag.
En vild gissning är att det kanske är ett 16-bitars heltal eller något i den stilen. Min räknare är uppe i 14818 nu, vilket blir ~2,57 dagar (och det stämmer med när jag senast startade om sändaren).

Mottagaren kanske använder det värdet för att se om det är flertalet datapaket som inte kommer fram, och slipper mäta tiden mellan paketen för att upptäcka det, utan bara behöver märka om det blir ett "glapp" i sekvensen på det här talet.

Åhh nu blev det tokigt... Jag funderade på total och analyserade seq... Gör om gör rätt.

@PHermansson: 'seq' som du refererar till är inget annat än en helt vanlig 16-bitars räknare som ökas med ett för varje paket som skickas. Om du vill veta mer ingående hur det fungerar kan du läsa min analys som jag länkade till ovan. Den benämns som PCnt i min text.

Den lilla stackars MSP430'n försöker skicka ett paket var 15:e sekund, men på decimalnivå över lång tid skulle jag inte lita på den.

Edit: Eller som Texas själva skriver i MSP430-dokumentationen: "The accuracy of the RTC depends on the accuracy of the crystal chosen for the crystal oscillator. This allows the user to purchase the appropriate crystal for the desired accuracy". Nu har mina 40+ ögon svårt att läsa vad som står på den där blanka lilla grejen, men om man anstränger sig så kan man kolla upp vilka feltoleranser Sparsnäs-konstruktören använt sig av

Mycket intressant Kodarn!
Jag funderar på d3, du har inte kommit fram till vad det är? Är det batterinivån, i den andra koden finns detta:

Är det någon som har en RFM96 över och som kan tänka sig sälja en till mig?