Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sparkfun Artemis and CS320 pyranometer #83

Open
jvoermans opened this issue Sep 14, 2021 · 16 comments
Open

Sparkfun Artemis and CS320 pyranometer #83

jvoermans opened this issue Sep 14, 2021 · 16 comments

Comments

@jvoermans
Copy link

Hi All, I've come across a sensor that communicates through SDI-12 and would be great to use a microcontroller to log the data.

Has anyone got experience using the CS320 pyranometer (Campbell Scientific) with the SDI-12 library?
Also, any experience with the SDI-12 library and the Sparkfun Artemis? @jerabaul29

Any feedback much appreciated

@jerabaul29
Copy link

I had a look, it seems like a bit of "board-specific definitions" is needed to make things work:

#else
#error "Please define your board timer and pins"
#endif

If we could get some help here it would be really great. Any hope @Wenn0101 that someone at SF could help us on that? We are quite big buyers of the AGTs for geophysical measurements (and we intend to use AGTs instead of Campbell systems to log / transmit data about these sensors in the future), and we are trying to push more people around us to go for these, if you can help us get this SDI-12 stuff to work this is more customers from Met organizations around the world :) .

Just putting the datasheet link: https://s.campbellsci.com/documents/us/manuals/cs320.pdf .

@neilh10
Copy link

neilh10 commented Sep 14, 2021

I'm just wondering if it also needs SDI12Timer:: class instances for that board in SDI12_boards.cpp

I've been looking at how to do this on Cortex-M4 SAMD51 (Seeed Wio Terminal). The registers/implementation for the SAMD51 TimerCounter are different than that of the SAMD21.

For a fast processor, and since the whole approach is port bit-banging, the ESP32/ESP8266 has perhaps a generic approach.
From SDI12.h:

  • @note The ESP32 and ESP8266 are fast enough processors that they can take the
  • time to read the core 'micros()' function still complete the other processing needed
  • on the serial bits. All of the other processors using the Arduino core also have the
  • micros function, but the rest are not fast enough to waste the processor cycles to
  • use the micros function and must use the faster assembly macros to read the
  • processor timer directly.

SDI12_boards.cpp: ESP32/8266 approach is pretty simple

void SDI12Timer::configSDI12TimerPrescale(void) {}
void SDI12Timer::resetSDI12TimerPrescale(void) {}
sdi12timer_t SDI12Timer::SDI12TimerRead(void) {
// Its a one microsecond clock but we want 64uS ticks so divide by 64 i.e. right shift 6
return ((sdi12timer_t)(micros() >> 6));
}

@jerabaul29
Copy link

Aaah, that would be very convenient if KISS bit banging with the micros function would be enough :) .

The Artemis runs at 48MHz with a boost mode (that works the same, just more power draw) at 96MHz. Any idea if that would be enough? :) .

@jerabaul29
Copy link

Any idea of a cheap SDI-12 device we could use just to test the communications? :) .

@neilh10
Copy link

neilh10 commented Sep 14, 2021

Yes the KISS is a good baseline. I would guess 48MHz should have a fast enough cycle time,... but its all in the trying it out. Thanks to whoever did the ESP32 for thinking it out .....

I'm trying it with a SAMD51, 120MHz (https://wiki.seeedstudio.com/Wio-Terminal-Getting-Started/)
and using the front right hand port with a Seeed connector, that maps to pin A1
For generic test I'm pressing an old 16bit version of https://vegetronix.com/Products/SDI-12-Sensor-Translator/ I've set it to address 1 in the past when testing with EnviroDIY Modular sensors.
However it needs 5.5V. So I've got a booster from the WioT 3.3V to +12V.
Starting with the i_SDI_12_interface.cpp, and modified similar to ESP32. It has compiled, downloaded and emitting SDI-12 protocol type characters, but the timing is off.
image

Maybe I should switch to a repeated a_wild_card.ino

@neilh10
Copy link

neilh10 commented Sep 15, 2021

welll... so a quick report, but it doesn't look good.
the CortexM devices have peripheral routing by the manufacturer. The ESP32 is RISC ~ which is the KISS principal, and the persumably delay() works, perhaps it has simple port perhipherals.
I guess you need to check with the Artemis how it does it.
For the SAMD51 my research on simple timing and bit-banging a port isn't encouraging and not what I expect.
Going back to basics, I set up a simple bit toggle, to generate a square wave, controlling the low and the high periods using a delay.
There are various sources of the timing that are available for the SAMD51 .platformio\packages\framework-arduino-samd-seeed
Using a standard;
delay(1) ms squ wave low is 949uS & high is 1047uS as measured by the Salae logic analyzer running at 100Mhz - I consider that pretty bad accuracy but its seems to get wors
For a custom delay_usec() to better control registers accessed, at the 1200baud bit rate of 866uS
delay_usec(866) low 813.4uS & high 922.2uS total time 1735uS
however at the SDI-12 bit sampling rate of 64uS
delay_usec(64) low 11.2uS & high 120.7uS ~ total 132.8uS - very skewed. Not good.

@jerabaul29
Copy link

Hi @neilh10 ,

Many thanks for your comments. Ok, interesting to hear that things do not look too good. We will discuss with @jvoermans if we try to find an alternative or go for SDI-12 interfaced sensors, we will let you know.

@jerabaul29
Copy link

There are many timers on the Sparkfun Artemis boards, so an option too is to go for the more involved "timer solution". Just for reference (in addition to the datasheet):

https://forum.sparkfun.com/viewtopic.php?t=52254

https://forum.sparkfun.com/viewtopic.php?t=51868

@neilh10 if you would be interested to look into this we could ship to you an Artemis RedBoard ( https://www.sparkfun.com/products/15444 ), which is a not too expensive board that uses the same processor as the whole Artemis family. Of course no pressure whatsoever though, we perfectly understand if you are not interested in supporting a multitude of boards and architectures :) .

@neilh10
Copy link

neilh10 commented Sep 15, 2021

@jerabaul29 I checked with the PlatformIO environment and it doesn't support the Sparkfun Artemis board. I have been using the https://platformio.org/ IDE, (using Visual Code) which when it supports a target is a very easy turn-up environment and supports a number of targets.
All I could really do would be to test the ability to generate a square wave from the internal delay loops. The target is the 1200Baud x 13 internal sampling or 64uS square wave. If that isn't accurate, within the SDI-12 spec of 10%, (say measured target of 5%) then the SDI-12.cpp isn't likely to work.
The multitude of timers, technically fantastic, often require a detailed driving knowledge.
There is a test setup https://github.com/addreas/platform-apollo3blue, I could try later and see if it goes in.
I am using ModualrSensors with the SDI12, with target deployments on https://monitormywatershed.org/ so that is mostly what I'm targeted on. The Artemis Apollo3 board doesn't seem a good fit with simple field deployment with no battery.
I'm still puzzling over the results I got with the SAMD51, so might try it on the similar SAMD12, which is supported.
Unfortunately this is the story with embedded microcontrollers, very fractured environemtn.
The other option for an accurate wave generation is to use the DMA and investigating how the interface to tri-colour leds work, They require very accurate edges to be generated.

@jerabaul29
Copy link

Yeah, platformio and the Artemis is a bit of a complicated story, but there is a good platformio support now - though this is community contributed and requires manual install:

https://github.com/nigelb/platform-apollo3blue

Ok, thanks. Will try to get my hand on a SDI-12 device and test. Really sad / painful with the "fractured" of the specs, library, etc, indeed as you say.

@jerabaul29
Copy link

Super nice website by the way :) .

@jerabaul29
Copy link

We rather use our systems for measurements of sea ice cover in the Arctic and Antarctic, so this is why we use these MCUs - since there is a development board version with iridium and GPS all on the same board that we like quite well ( https://www.sparkfun.com/products/16469 ). The nice thing with these Artemis boards is that they are based on these Ambiq processors that use around 0.5mA at 3.3V when running at full 48MHz with everything on :) .

@neilh10
Copy link

neilh10 commented Sep 16, 2021

Gosh thanks for the insights, and link to nigelb/platform-apollo3blue. I'll see if it goes in as easy as it suggests.
My career is with embedded MCUs, first with Motorola D2 6800 kit with a teletype interface, then intel 8048 (RIP silicon souls).
The 0.5mA is very nice as is the integration with Artemis Global tracker.
Looking at the Apollo3, for me its lacking in UART and integrated USB (Host open source is still a mirage). Apollo4 seems to include 4 UARTs and a USB 2. .
Also interested in your blog https://jerabaul29.github.io/jekyll/update/2020/12/20/using-sparkfun-artemis.html on Arduino mbed version.

monitormywatershed.org is a project of the Stroud Water Research center, and they have enviroDIY.org to encourage users and a mega1284 board Mayfly with the SDI-12. I'm a user, and have my own fork of the software https://github.com/neilh10/ModularSensors

@jerabaul29
Copy link

Nice! I (and @jvoermans ) are working in Geosciences (in opposite parts of the world), measuring sea ice dynamics in the Arctic and Antarctic. We are developing our own instrumentation (which we open source when its mature, but working on a new "v2021" that is not open yet, still too early phase), since it can cut costs by a factor 10 to 15 compared with commercial solutions, and it makes a big difference for the science we work on if we have 1 or 20 measurement points...

The ironic part is that in the project I work with now, I actually decided to stick to the core v1 which is a "simple C++ main program running" and not using the RTOS, since a bunch of stuff was not really stable when I started the project back then. But I think that the MbedOS based arduino core is getting much better these days. This is the nice thing with the SF Artemis platform, there is an actual company behind and a relatively large users community, so that there is tooling examples etc made available.

@neilh10
Copy link

neilh10 commented Sep 17, 2021

@jerabaul29 I followed the https://github.com/nigelb/platform-apollo3blue
Just wondering Is that the environment you've tried at all.?

Its almost compiled, except for finding interrupts() nointerrupts()

I've tried the ARTEMIS_THING_PLUS as I've used the feather footprint before.

C:\Users\neilh77a.platformio\packages\framework-arduinoapollo3@2.1.0\cores/mbCOLLECT_GCC_OPTIONS='-o' '.pio\build\SparkFun_Thing_Plus\src\SDI12_boards.cpp.o'
'-c' '-MMD' '-include' 'C:\Users\neilh77a.platformio\packages\framework-arduinoapollo3@2.1.0\variants\SFE_ARTEMIS_THING_PLUS\mbed\mbed_config.h'
'-include' 'C:\Users\neilh77a.platformio\packages\framework-arduinoapollo3@2.1.0\cores\arduino\sdk\ArduinoSDK.h'
'-iprefix' 'C:\Users\neilh77a.platformio\packages\framework-arduinoapollo3@2.1.0\cores/' '-c' '-fno-rtti' '-std=gnu++14'
'-D' 'MBED_MINIMAL_PRINTF' '-D' 'MBED_TRAP_ERRORS_ENABLED=1' '-Os' '-fdata-sections' '-ffunction-sections' '-fmessage-length=0' '-fno-exceptions' '-fomit-frame-pointer'
'-funsigned-char' '-mcpu=cortex-m4' '-mfloat-abi=hard' '-mfpu=fpv4-sp-d16' '-mthumb' '-iwithprefixbefore' 'mbed-os' '-iwithprefixbefore' 'mbed-os/cmsis' '-iwithprefixbefore'
'mbed-os/cmsis/TARGET_CORTEX_M' '-iwithprefixbefore' 'mbed-os/components' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/atmel-rf-driver' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/atmel-rf-driver/atmel-rf-driver' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/atmel-rf-driver/source' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/mcr20a-rf-driver' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/mcr20a-rf-driver/mcr20a-rf-driver' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/mcr20a-rf-driver/source' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/stm-s2lp-rf-driver' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/stm-s2lp-rf-driver/source' '-iwithprefixbefore' 'mbed-os/components/802.15.4_RF/stm-s2lp-rf-driver/stm-s2lp-rf-driver' '-iwithprefixbefore' 'mbed-os/components/storage/blockdevice/COMPONENT_FLASHIAP' '-iwithprefixbefore' 'mbed-os/components/storage/blockdevice/COMPONENT_FLASHIAP/COMMON' '-iwithprefixbefore' 'mbed-os/components/wifi' '-iwithprefixbefore' 'mbed-os/components/wifi/esp8266-driver' '-iwithprefixbefore' 'mbed-os/components/wifi/esp8266-driver/ESP8266' '-iwithprefixbefore' 'mbed-os/drivers/internal' '-iwithprefixbefore' 'mbed-os/events' '-iwithprefixbefore' 'mbed-os/events/internal' '-iwithprefixbefore' 'mbed-os/features' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/ble' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/ble/common' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/ble/gap' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/ble/generic' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/ble/pal' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/ble/services' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/source' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/source/gap' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/source/generic' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_Ambiq_Micro' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_Ambiq_Micro/TARGET_Apollo3' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_Ambiq_Micro/hal' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_Ambiq_Micro/hal/apollo3' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/driver' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/source' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/stack' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/stack/ble-host' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/stack/ble-host/include' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/stack/ble-host/sources' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/stack/ble-host/sources/hci' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/stack/ble-host/sources/hci/dual_chip' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targets/TARGET_CORDIO/stack/ble-host/sources/sec' '-iwithprefixbefore' 'mbed-os/features/FEATURE_BLE/targetsed-os/rtos/source/TARGET_CORTEX/rtx5/RTX/Include

@jerabaul29
Copy link

For now I am using the Arduino IDE still, but I have some colleagues who use the Platformio environment and said it worked nicely. If you have any issues, please report these directly on the platformio repo :) .

Another thing: you can choose either to use the core v1 or v2 with platformio. The people I know all use the core v1, no idea how stable the core v2 (the one with RTOS) is. If you want to discuss this further, may you open an issue at nigelb's repo (feel free to tag me there if you want :) ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants