Node Set-up & Test
I have only recently moved more generally into a Node production, rather than prototyping mode and with this now have a greater need for a consistent testing regime for the various board elements. Physical testing of the various hardware configurations is discussed in the relevant Hardware Assembly pages. The present section focuses on elements of configurations that require software to establish that they are functioning as intended.
While the intent is to ultimately have a set of test procedures that apply universally to individual subunits, regardless of the supporting processor, the initial procedures described below have only been tested with configurations that have 'gone into production', as it were. The first board in this category is the CubeCell Dev-Board Plus 10068-BHCP PCB and, for the time being, the following apply only to this board. Nonetheless, most sketches will require only minor modification, if any, to run on different processors and I will ultimately provide sketches that are universally applicable.
Details of procedures for testing individual sensors will ultimately be provided through the Software > Sensors pages.
The following are currently not much more than the notes I am making as I work through the process of assembling these boards for their various applications—in a sense these are the beginnings of the software equivalent of the Hardware Assembly instructions provided elsewhere on this site. I'll come back and tidy all this up when I have a better view of the whole process.
Boost Converter
The boost converter is a hardware-only element. Refer to the relevant Hardware Assembly pages for testing details.
EEPROM Initialisation
When using the EepromHandler library, EEPROMs should first be initialised with the Node identification details. This will include the MAC addresses of both the Node and its Gateway, as well as a Node name or general description, and initial values for various counters (for details of the EEPROM logical structure, refer to the EEPROM Handler page). I have always planned to be able to derive this information dynamically, during some automated setup procedure, but for the time being these details need to be input manually.
After soldering the EEPROM and the I2C pull-up resistors, and before initialising the EEPROM, we need to ensure that the I2C bus is operational—use an I2C port scanner if necessary to verify that you can 'see' the EEPROM.
|
I2C Port Scanner | 02-Dec-2023 | [2 KB] |
The 'base' EEPROM I2C address is 0x50. Due to the way in which the contents of an EEPROM are accessed, and the limitations of I2C addressing, this only provides access to first 256 bytes of storage in EEPROMs up to 16K. To access more, different I2C devices addresses—0x50 .. 0x57—must be used. Refer to the discussion on EERPROM addressing in the EEPROM Handler pages for more detail.
The EEPROM Setup utility [ResetEEPROM], which can be downloaded from the EERPOM Downloads page, provides a mechanism to set the Node and Gateway MAC Addresses, the Node name/description, the initial message Sequence Number, and any 'persistant' counters that are required by a target application.
Interrupt Button
To verify that the interrupt button is operating as intended, load the InterruptTest sketch (below) and verify that appropriate messages are generated in the Serial Monitor when the interrupt button is pressed.
|
|
Interrupt Button Test | 01-Dec-2023 | [1 KB] |
For a more advanced interrupt button test, load the InterruptRisingFallingTest sketch (below). This sketch generates interrupts when the button is both pressed and released and reports the duration of the button press. This functionality can be used to execute different tasks based on the duration of a button press.
|
|
Interrupt Button Press Duration Test | 01-Dec-2023 | [2 KB] |
Power Source [Vext/Vint] Switch
To verify that the Vext/Vint power source switch is operating as intended, load the VextTest sketch (below) and measure the voltage at the Boost Converter test points. The sketch turns Vext ON and OFF at 5 second intervals.
To check that Vext is being controlled correctly, set the switch to Vext and verify that the power is turned ON and OFF as indicated by the Serial Monitor output from the sketch.
With the Power Source Switch set to Vint, power should be ON whenever the processor is powered.
To check that the switch is also controlling the voltage supplied to the various sensor sockets, the power pins on each or any can also be measured.
|
|
Vext Test | 01-Dec-2023 | [1 KB] |
TPL5010 Watchdog Timer
The Watchdog Timer test sketch can be used to verify the setup of the timer. It outputs time stamps at one second intervals to ultimately record the timer duration—timer duration is determined at power-on by the value of the resistor elements [R10A and/or R10B] in the timer circuit.
Watchdog Timer Schematic
Note that the timer circuit is configured with two possible resistor configurations—fixed [R10A] or variable [R10B]. Either way, the value of the resistance can be measured through the tap points—labelled R10—provided adjacent to the circuit elements on the PCB.
 |
 |
Watchdog Timer Resistance Tap Points (10068-BHCP [v2.5] illustrated)
If the variable resistor option has been configured, set the trimpot to the desired resistance. The forumla used to determine the relationship between the resistance used in the timer circuit and the elapsed time is provided in the TPL5010 Datasheet, but some typical resistance values and associated timings are provided in the following table.
Time vs Resistance
| Delay | Resistance (kΩ) |
|---|---|
| 2s | 6.8 |
| 3s | 7.6 |
| 20s | 14.4 |
| 30s | 16.8 |
| 1m | 22.0 |
| 2m | 29.4 |
| 5m | 42.9 |
| 10m | 57.4 |
| 20m | 77.6 |
| 30m | 92.4 |
| 1h | 124.9 |
| 2h | 170.0 |
In general, when working with a reporting interval of 60 seconds, and assuming that the 'dog' is patted each time a report is sent out, I set the watchdog timer to ~90 seconds, using a resistance value of ~25kΩ. Note that the timer setting needs to take into account both the reporting interval (the time between measurements) and the time spent during each reporting cyce actually taking measurements. If, for example, it takes 10 seconds to take measurements from sensors, and the reporting interval is 60 seconds, the time elapsed between reports will be 70 seconds.
|
|
Watchdog Timer Test | 01-Dec-2023 | [2 KB] |