{"id":135774,"date":"2018-10-19T15:28:00","date_gmt":"2018-10-19T12:28:00","guid":{"rendered":"https:\/\/ruuvi.com\/ruuvi-firmware-teil-13-batteriemessung-mit-funk-synchronisiert\/"},"modified":"2026-06-11T07:40:35","modified_gmt":"2026-06-11T04:40:35","slug":"ruuvi-firmware-teil-13-batteriemessung-mit-funk-synchronisiert","status":"publish","type":"post","link":"https:\/\/ruuvi.com\/de\/ruuvi-firmware-teil-13-batteriemessung-mit-funk-synchronisiert\/","title":{"rendered":"Ruuvi Firmware \u2013 Teil 13: Batteriemessung mit Funk synchronisiert"},"content":{"rendered":"\n
\"Introbild<\/figure><\/div>\n\n

In diesem Teil des Tutorials synchronisieren wir die Messung der Batteriespannung mit Funk\u00fcbertragungen. Den finalen Code dieses Blogposts kannst du bei Ruuvi GitHub<\/a> im Branch ruuviblog<\/em>, Tag 3.13.0-alpha<\/em> herunterladen. <\/p>\n\n

Bitte folge Teil 1 der Serie<\/a> f\u00fcr Details zum Klonen des Repositories und Kompilieren des Codes. Die finale Hex-Datei dieses Tutorials kann vom Ruuvi Jenkins<\/a> heruntergeladen werden. <\/p>\n\n

Update auf SDK 15.2<\/h2>\n\n

Im vorherigen Teil des Blogs haben wir das Nordic Software Development Kit<\/em><\/a> (SDK<\/strong>) in Version 15.2 f\u00fcr den Bootloader-Code und Softdevice s132 6.1.0<\/em><\/a> als Funk-Software verwendet. Aktualisieren wir jetzt auch das Hauptprojekt. <\/p>\n\n

Das Update ist schnell erledigt: Wir suchen das alte SDK<\/strong> und ersetzen es in der Projektdatei durch das neue SDK<\/strong> und entfernen das Pr\u00e4fix \u201eexperimental_\u201c in den Pfaden log<\/em>, ringbuf<\/em> und memobj<\/em>. Die Datei pm_mutex.c<\/em> wird entfernt. Zus\u00e4tzlich #define <\/em>NRF_LOG_STR_PUSH_BUFFER_SIZE APPLICATION_LOG_BUFFER_SIZE<\/strong> in nrf5_sdk15_application_config.h<\/em>, damit die Makrobenennung zum SDK15.2 <\/strong>-Logging passt. Das Logging nutzt jetzt ringbuf.c<\/em>, wir f\u00fcgen es dem Build hinzu. Dann reservieren wir in unserer flash_placement.xml<\/em> Platz f\u00fcr log_backends<\/em>, indem wir eine Definition zu den Flash-Sektionen hinzuf\u00fcgen: <\/p>\n\n

<ProgramSection alignment=\"4\" keep=\"Yes\" load=\"Yes\" name=\".log_backends\" inputsections=\"*(SORT(.log_backends*))\" address_symbol=\"__start_log_backends\" end_symbol=\"__stop_log_backends\" \/><\/code><\/pre>\n\n
Die Clock-Enable-Direktive hat sich ebenfalls von CLOCK_ENABLED<\/strong> zu NRF_CLOCK_ENABLED<\/strong> ge\u00e4ndert, daher f\u00fcgen wir einen Wrapper in sdk_config.h<\/em> hinzu<\/p>\n\n
#ifndef NRF_CLOCK_ENABLED\n#define NRF_CLOCK_ENABLED CLOCK_ENABLED\n#endif<\/code><\/pre>\n\n
Nordic hat dem SDK<\/strong> Definitionen f\u00fcr nfc_fixes.h<\/em> hinzugef\u00fcgt, wir ben\u00f6tigen daher die Definition HAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND<\/strong> in den in ruuvi.firmware.c.emProject<\/em> definierten Preprocessor-Makros nicht mehr. Nach dem Entfernen kompiliert das Projekt ohne Warnungen, und wir k\u00f6nnen auf Basis des aktualisierten SDK<\/strong> weiterbauen. Vor dem Flashen muss die Softdevice<\/em>-Version in der Projektdatei auf 6.1.0 aktualisiert werden.  <\/p>\n\n
Batteriemessung erneut betrachtet<\/h2>\n\n
Seit Teil 11 \u2014 Scheduler<\/a> messen wir die Batteriespannung in einem Intervall von ungef\u00e4hr 30 Sekunden, ohne darauf zu achten, wie das Programm sonst l\u00e4uft.<\/p>\n\n
Das ist bei einer frischen Batterie bei Raumtemperatur ein guter Ansatz. Wenn jedoch der Innenwiderstand der Batterie durch K\u00e4lte und Entladung steigt, erleben wir w\u00e4hrend der Spitzenlast \u2013 der Funkaktivit\u00e4t \u2013 einen Spannungseinbruch an der Batterie.<\/p>\n\n
Daher registrieren wir einen Event-Handler, der nach einer Funk\u00fcbertragung aufgerufen wird, und pr\u00fcfen darin, ob es Zeit ist, eine weitere Messung mit dem Analog-Digital-Wandler (ADC<\/strong>) an der Batterie durchzuf\u00fchren.<\/p>\n\n
Schnittstelle<\/h2>\n\n
Wir haben bereits ein Funkaktivit\u00e4ts-Event in ruuvi_interface_communication_radio.h<\/em> definiert. Wir f\u00fcgen eine Funktion hinzu, um in Zeile 41 einen Application-Event-Handler f\u00fcr Funk-Interrupts einzurichten: <\/p>\n\n
typedef enum\n{\n  RUUVI_INTERFACE_COMMUNICATION_RADIO_BEFORE,\n  RUUVI_INTERFACE_COMMUNICATION_RADIO_AFTER\n}ruuvi_interface_communication_radio_activity_evt_t;\n\ntypedef enum\n{\n  RUUVI_INTERFACE_COMMUNICATION_RADIO_UNINIT = 0,\n  RUUVI_INTERFACE_COMMUNICATION_RADIO_ADVERTISEMENT,\n  RUUVI_INTERFACE_COMMUNICATION_RADIO_GATT,\n  RUUVI_INTERFACE_COMMUNICATION_RADIO_MESH\n}ruuvi_interface_communication_radio_user_t;\n\n\/**\n *  Type of radio activity interrupt. This is common to all radio modules, i,e, the callback gets called for every radio action.\n *\/\ntypedef void(*ruuvi_interface_communication_radio_activity_interrupt_fp_t)(const ruuvi_interface_communication_radio_activity_evt_t evt);\n\n\/\/ Enable \/ disable radio stacks\nruuvi_driver_status_t ruuvi_interface_communication_radio_init  (const ruuvi_interface_communication_radio_user_t handle);\nruuvi_driver_status_t ruuvi_interface_communication_radio_uninit(const ruuvi_interface_communication_radio_user_t handle);\n\n\/**\n * Writes maximum 64-bit unique address of the device to the pointer. This address\n * may be changed during runtime. The address is identifier of the device on radio network,\n * such as BLE MAC address.\n *\n * parameter address: Output, value of address.\n *\n * return RUUVI_DRIVER_SUCCESS on success\n * return RUUVI_DRIVER_ERROR_NOT_SUPPORTED if address cannot be returned on given platform\n *\/\nruuvi_driver_status_t ruuvi_interface_communication_radio_address_get(uint64_t* const address);\n\n\/**\n * Setup radio activity interrupt\n *\n * parameter handler: Function to call on radio event NULL to disable radio-level callback, however module-level callbacks (advertising, GATT etc) will be called.\n *\/\nvoid ruuvi_interface_communication_radio_activity_callback_set(const ruuvi_interface_communication_radio_activity_interrupt_fp_t handler);<\/code><\/pre>\n\n
Rohdaten anzeigen<\/a><\/p>\n\n
Treiber<\/h2>\n\n
Als N\u00e4chstes implementieren wir die Schnittstelle in nrf5_sdk15_platform\/ruuvi_platform_communication_radio.c<\/em>. Wir f\u00fcgen einen statischen Funktionszeiger hinzu, der gesetzt werden soll, sowie eine Setup-Funktion. Dann f\u00fcgen wir einen Handler f\u00fcr den Softdevice<\/em>-Funkinterrupt hinzu, der den Funktionszeiger aufruft, sowie einen Event-Handler des Advertising-Moduls, falls wir sp\u00e4ter advertising-spezifische Aktionen ausf\u00fchren m\u00f6chten.  <\/p>\n\n
In Zeile 43 haben wir die Interrupt-Initialisierung ble_radio_notification<\/em> hinzugef\u00fcgt. Die Interrupt-Priorit\u00e4t ist in application_config\/ruuvi_platform_nrf5_sdk15_config.h<\/em> als 2<\/em> definiert, das ist die h\u00f6chste Application-Priorit\u00e4t. \u201eDistance\u201c definiert, wie lange vor und nach dem Event der Interrupt ausgel\u00f6st wird; 800 \u03bcs<\/em> ist der kleinste Abstand, den wir erreichen k\u00f6nnen.  <\/p>\n\n
\/\/ Application callback for radio events\nstatic ruuvi_interface_communication_radio_activity_interrupt_fp_t on_radio_activity_callback = NULL;\n\n\/**\n * Task to run on radio activity - call event handlers of radio modules and a common radio event handler.\n * This function is in interrupt context, avoid long processing or using peripherals.\n * Schedule any long tasks in application callbacks.\n *\n * parameter active: True if radio is going to be active after event, false if radio was turned off (after tx\/rx)\n *\/\nstatic void on_radio_evt(bool active)\n{\n\n  ruuvi_interface_communication_radio_activity_evt_t evt = active ? RUUVI_INTERFACE_COMMUNICATION_RADIO_BEFORE : RUUVI_INTERFACE_COMMUNICATION_RADIO_AFTER;\n  \/\/ Call advertising event handler\n  ruuvi_platform_communication_ble4_advertising_activity_handler(evt);\n\n  \/\/ Call common event handler if set\n  if(NULL != on_radio_activity_callback ){ on_radio_activity_callback(evt); }\n\n}\n\nruuvi_driver_status_t ruuvi_interface_communication_radio_init  (const ruuvi_interface_communication_radio_user_t _handle)\n{\n  if(RUUVI_INTERFACE_COMMUNICATION_RADIO_UNINIT != handle) { return RUUVI_DRIVER_ERROR_INVALID_STATE; }\n\n  ret_code_t err_code = NRF_SUCCESS;\n  handle = _handle;\n  err_code = nrf_sdh_enable_request();\n  RUUVI_DRIVER_ERROR_CHECK(err_code, NRF_SUCCESS);\n\n  \/\/ Configure the BLE stack using the default settings.\n  \/\/ Fetch the start address of the application RAM.\n  uint32_t ram_start = 0;\n  err_code |= nrf_sdh_ble_default_cfg_set(NRF5_SDK15_BLE4_STACK_CONN_TAG, &ram_start);\n  RUUVI_DRIVER_ERROR_CHECK(err_code, NRF_SUCCESS);\n\n  \/\/ Enable BLE stack.\n  err_code |= nrf_sdh_ble_enable(&ram_start);\n  RUUVI_DRIVER_ERROR_CHECK(err_code, NRF_SUCCESS);\n\n  \/\/ Initialize radio interrupts\n  err_code |= ble_radio_notification_init(NRF5_SDK15_RADIO_IRQ_PRIORITY,\n                                          NRF_RADIO_NOTIFICATION_DISTANCE_800US,\n                                          on_radio_evt);\n\n  return ruuvi_platform_to_ruuvi_error(&err_code);\n}\n\n.\n.\n.\n\nvoid ruuvi_interface_communication_radio_activity_callback_set(const ruuvi_interface_communication_radio_activity_interrupt_fp_t handler)\n{\n  \/\/ Warn user if CB is not NULL and non-null pointer is set, do not overwrite previous pointer.\n  if(NULL != handler && NULL != on_radio_activity_callback) { RUUVI_DRIVER_ERROR_CHECK(RUUVI_DRIVER_ERROR_INVALID_STATE, ~RUUVI_DRIVER_ERROR_FATAL); }\n  else { on_radio_activity_callback = handler; }\n}<\/code><\/pre>\n\n
Rohdaten anzeigen<\/a><\/p>\n\n
Testen<\/h2>\n\n
Der \u00dcbersichtlichkeit halber ist der Zwischenstand w\u00e4hrend der Entwicklung hier nicht enthalten, der finale Code wird sp\u00e4ter gezeigt. Kurz gesagt: Die ADC<\/strong>-Task wurde so eingestellt, dass sie beim Funkinterrupt den ADC<\/strong> sampelt und einen General-Purpose-Input\/Output-Pin (GPIO<\/strong>) toggelt. Dieses Toggling wurde genutzt, um Oszilloskopmessungen an der Versorgungsspannung zu triggern. Zuerst wurde eine wenig genutzte Batterie getestet.  <\/p>\n\n
\"Oszilloskop
Blaue Linie ist DC-gekoppelt an GPIO, rote Linie ist AC-gekoppelt an der Batteriespannung<\/figcaption><\/figure><\/div>\n\n
Die AC-gekoppelte<\/em><\/a> Linie zeigt, dass wir einen Einbruch von etwa 150 mV<\/em><\/strong> auf der Leitung haben, und das ADC-Sample trifft nicht exakt den niedrigsten Punkt. Die Versorgungsspannung liegt etwas \u00fcber 3 V<\/em>. Als N\u00e4chstes pr\u00fcfen wir eine entladene CR2450-Batterie aus der Kickstarter-\u00c4ra 2016.  <\/p>\n\n
\"Oszilloskop
Blaue Linie ist DC-gekoppelt an GPIO, rote Linie ist AC-gekoppelt an der Batteriespannung<\/figcaption><\/figure><\/div>\n\n
Hier sehen wir einen deutlich tieferen Einbruch von \u00fcber 500 mV<\/em><\/strong>, obwohl die Ruhespannung ebenfalls etwas \u00fcber 3 V<\/em> liegt. Das bringt uns auf eine Idee: Wie w\u00e4re es, statt der absoluten Spannung die Tiefe des Spannungseinbruchs zu nutzen, um den Batteriezustand zu bestimmen? Diese Idee schauen wir uns sp\u00e4ter noch an.  <\/p>\n\n
Integration in die Anwendung<\/h2>\n\n
Jetzt haben wir 3 unterschiedliche Modi f\u00fcr den ADC-Betrieb:<\/p>\n\n