Custom PCB with Teensy4.1, ESP32 and SIM7600

[danieltsz]

PAGASA Custom Environmental Datalogger (Revision 0)​

After months of research, hardware design, firmware development, and testing, I am proud to present Revision 0 of our custom-built environmental datalogger, engineered specifically for the operational requirements of the Philippines' Weather Bureau, the Philippine Atmospheric, Geophysical and Astronomical Services Administration (PAGASA).

Designed around the Teensy 4.1 microcontroller, the system integrates an ESP32 for Wi-Fi connectivity and a SIM7600 LTE modem for cellular communication, providing a powerful, flexible, and highly reliable telemetry platform for hydrometeorological monitoring.

The datalogger is intended for deployment at remote weather and hydrological monitoring stations, where it continuously acquires field measurements and transmits them to PAGASA's command center for real-time flood forecasting and early warning operations.

To maximize data availability in remote environments, the datalogger employs a three-level communication architecture with automatic failover.

​

VHF Radio (UART via TTL-to-RS232)
The primary telemetry channel uses a VHF radio modem for long-range communication between remote stations and the command center.

Secondary Communication (MQTT over Wi-Fi or LTE)​

If no acknowledgement is received through the VHF network, the datalogger automatically retransmits the data using MQTT through either:

• Integrated ESP32 Wi-Fi
• SIM7600 LTE cellular connection

SMS Fallback
If both VHF and MQTT transmissions remain unsuccessful, the system automatically sends the observation through SMS, providing another layer of redundancy for mission-critical hydrological data.

This communication hierarchy ensures that valuable field observations continue reaching the command center even when one or more communication channels become unavailable.


Revision 0 combines high-performance processing with extensive connectivity in a single compact platform.

Core Hardware​

• Teensy 4.1 (600 MHz ARM Cortex-M7)
• ESP32 Wi-Fi Module
• SIM7600 LTE Cellular Modem
  
  • LTE Data
  • MQTT
  • SMS
  • Bluetooth
  • GNSS

Communication Interfaces​

• UART
• SDI-12
• RS-485
• CAN Bus
• I²C
• SPI

Data Acquisition​

• Integrated ADS1115 16-bit ADC
• MicroSD data storage
• Real-time sensor acquisition

The MQS audio interface allows the datalogger to play WAV audio files stored on the SD card, which can be connected to an external amplifier and siren system for automated voice announcements and emergency warning broadcasts.

The platform has been developed specifically for hydrometeorological monitoring applications, including:

• Automatic Weather Stations (AWS)
• Water Level Monitoring Stations
• Rainfall Monitoring Stations
• Flood Forecasting and Warning Systems
• Remote Environmental Monitoring Stations

Its modular architecture also allows new sensors and communication technologies to be integrated as operational requirements evolve.

Planned Upgrades

• 8 MB PSRAM for expanded runtime memory
• 128 MB Flash memory for increased storage capacity
• Upgrade from ADS1115 (16-bit, I²C) to ADS1258 (24-bit, SPI) for higher-resolution analog measurements and faster multi-channel sampling
• Larger OLED display for improved diagnostics and field operation
• Additional firmware optimizations and expanded sensor compatibility
• Looking ahead, one of the planned improvements is to have the Teensy 4.1 directly interface with SDI-12 sensors. This will streamline the hardware architecture, reduce dependency on the ESP32 for sensor communication, and centralize data acquisition in the primary controller.

 

[danieltsz]

Acknowledgements

I want to extend my sincere gratitude to @PaulStoffregen, creator of the Teensy platform, for his guidance and valuable support throughout the development and testing of this project. His expertise and contributions to the Teensy ecosystem have been instrumental in making this platform possible.

I would also like to thank @h4yn0nnym0u5e for the excellent Audio library. Without this library, implementing WAV file playback directly from the microSD card for voice announcements and emergency warning broadcasts would not have been possible.

Their work and support have greatly contributed to the successful development of this datalogger.

 

[h4yn0nnym0u5e]

I can’t lay claim to the Audio library, it’s part of Teensyduino, and the work of many hands. The buffered SD playback, yes - and with luck that will be pulled into the official release some time…

I did a quick search, and can’t find any repositories with this in - is it closed-source?

 

[danieltsz]

I can’t lay claim to the Audio library, it’s part of Teensyduino, and the work of many hands. The buffered SD playback, yes - and with luck that will be pulled into the official release some time…

I did a quick search, and can’t find any repositories with this in - is it closed-source?

i used the buffered-sd-audio-evr branch

 

[danieltsz]

I can’t lay claim to the Audio library, it’s part of Teensyduino, and the work of many hands. The buffered SD playback, yes - and with luck that will be pulled into the official release some time…

I did a quick search, and can’t find any repositories with this in - is it closed-source?

actually i dont know the difference between the buffered-sd-audio for PR and EVR, i just used it and it works like charm

 

[h4yn0nnym0u5e]

I was referring to your project when I said I can't find any repos...

actually i dont know the difference between the buffered-sd-audio for PR and EVR, i just used it and it works like charm

Thanks for this. I just merged the buffered-SD-audio-EvR branch into buffered-SD-for-PR. The EvR one was the latest and greatest, having a number of fixes which allow read/write use of the SD card from your sketch even while audio is streaming from it...

TL;DR - it didn't work before; now it can, if you're careful

The intention was that it should work, because streaming SD access only happens in yield(), and that's only called from your sketch, not under interrupt (like the AudioPlaySdWav does, and breaks things). However ... the SdFat library, while halfway through an SD access, can itself call yield() ... which might cause an EventResponder response try to load more audio data ... from SD . This Generally Ends Badly.

There's docs/bufferedPlayRec.md, and an example in RecSynthMusicV3.ino, showing what to do if you need other SD access while streaming audio. You say you have micro SD data storage, so unless your program structure guarantees that you only log while audio is not playing, you should take a look at that and modify your code accordingly. If you have questions, please post on this thread so anything helpful I manage to come up with is in what I think of as the Right Place!

Of course, you may already have done this. If so, congratulations