Student project, vibration monitoring on a lab fan rig. Arduino Nano samples an ADXL345 at 200 Hz (x, y, z), and sends each sample as a text line over an XBee S2C in transparent mode at 115200 baud. A second XBee (coordinator) on a Raspberry Pi receives, and a Python script publishes every line to Hermetry.
Problems: lots of lines arrive cut in half or not at all, and when I measure how much actually gets through it’s around 20 kbps. The datasheet says 250 kbps. Also in Hermetry the chart looks gappy and I keep getting notices about the device’s rate limit.
Sample line: t=123456,x=0.012,y=-0.981,z=0.044
Are you sending one line per sample, so 200 radio packets a second?
Yes. One Serial.println per sample.
Lower the serial baud to 9600 and see if it stabilises?
Tyler, lower baud would make it worse here, there’s even less room for 200 lines a second. Liam has three separate bottlenecks.
The radio. 250 kbps is the raw air rate of 802.15.4. After framing, Zigbee network and APS headers, acknowledgements, retries and channel access, real application throughput for unicast is in the tens of kbps. Each RF packet carries around 80 bytes of payload at most, less with encryption. 20 kbps is roughly what everyone measures.
The serial side. In transparent mode the XBee buffers your bytes and sends a packet when it goes quiet for a moment or the buffer fills. At 115200 in, ~20 kbps out, the buffer overflows and bytes are lost, which is your half lines. Turn on CTS flow control (D7) and honour it in the sketch, or better, switch to API mode and send binary frames: pack 10 samples (3 × int16 each) into one 60-byte frame.
Hermetry. Publishing each sample as its own message is 200 messages a second from one device. The default profile limits are 10 messages a second and 200 data points a second, go over them and owners get a notice, keep going over and the session gets closed, so those are your warnings. Even batched, 600 values a second is far more than the per-device point limit and the organisation’s per-minute data points.
For a fan rig, compute features on the Pi: per axis RMS and peak every second, maybe crest factor. That’s 6 to 9 values in one message per second, comfortably inside the limits, and a much more useful chart than raw g values.
Limits are on MQTT under Limits.
Switched to API mode with 10 samples per frame and the radio side is clean now, no lost frames in 20 minutes. The Pi sends x/y/z RMS and peak once a second. My supervisor actually prefers the RMS chart. I didn’t know about the per-device limits at all, that explains the warnings.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.