Marvin + SHT31 + MAX44009

Trying to make a small, remote weatherstation with 2* Temp&Hum-sensor using sensor type SHT31 + 1*lightsensor MAX44009 (= all I2C).
Managed to connect the SHT31 to Marvin, but no solution yet for MAX44009.

Looking for hints/scripts to handle MARVIN in combination with MAX44009, aiming at full performance of that sensor, providing high resolution light data through TTN to Domoticz.

Have to upgrade/modify the described Marvin_setup_with_SHT31s to interface with TTN_v3.
Search by Google, in the TTN-forum and in online-manuals does not clearly/simply reveal howto:
before ‘reinventing the wheel’, any experience/hints in this forum on this subject?

Good detail for sensors - the only Marvin that springs to mind is the Paranoid Android - there are 100’s of base devices available.

Improvements, apart from a better description of the device, is links to the things that you are stuck on - so a link to the MAX44009 and to the device. Do not link to any online manuals, no version control so can be very random, authoritative sources are the best (ie the manufacturers site) - a direct link to the product.

The volunteers can help, but they can help faster if you grease the slope as much as possible. So says 40 years programming :wink:

Nick,

:wink: Definitely a different Marvin to be looked at:
https://www.rdmmakerspace.nl/marvin/
The original hookup-documentation for that device from the manufacturer/supplier/integrator can be found here:
https://drive.google.com/drive/folders/0B3qKsQNZF5ygbldQMzRFTnA5RzA?resourcekey=0-Hbv54cjfzXMs2bemrd1iVA
In present perspective, the following question as 1st milestone:
how do I setup the firmware for communication with TTN_v3 to get data to the Console?
May raise eyebrows, but in the original setup they use KPN_Lora.
More or less expecting that Dutch users of Marvin have first experimented with this KPN_Lora (as part of the setup package for Marvin), and after trial period shifted to TTN, because of cost.
However, on internet only found shifts from KPN_Lora to TTN_v2 and not to TTN_v3:
being unexperienced in both TTN-versions, trying to find guidance.
Related aspect (looking ahead, preparing data for further application after extraction from the TTN-server):
would HTTP-integration be the easiest mode of data-transfer?

To ease setup effort, the desired integration to be limited to:

  • linking to TTN_v3 with those SHT31s as example-test-vehicles for the integration mode.
    The Marvin_PCB having an Arduino Leonardo as kernel, linking of SHT31s (IMHO) seems the easy part.

Operation with Maxim44009 as per https://www.analog.com/media/en/technical-documentation/data-sheets/max44009.pdf , (to avoid confusion of efforts) suggested at later date to be treated in another thread.

LoRaWAN is a standard, register it on TTS CE and put the credentials on to the device.

As it has a RN module on, it may benefit from a firmware update - search for the RN module device/number for how-to/info.

The MAX44009 has an Arduino library from Rob Tillaart which with the magic of Google I found using “max44009 arduino” - Rob being a known entity in the Arduino eco-system aka knows what he’s doing - but as you are retired, no harm in writing your own driver :stuck_out_tongue_winking_eye:

Nick,

Will try to follow the lead given in your latest message.

:wink: compatible search-key is decisive for outcome:
after identifying&reporting 44009-info to meet your suggestion, also found myself another Arduino-script.
One more reason to postpone effort on that aspect, and concentrate on solving the basic Marvin-integration towards TTS.

Hope the version you have is newer than that shown in the picture (from their Kickstarter effort?)…it shows the RN2483 not even the 83’A’ a later revision that took care of a few bugs and issues (@ higher SF’s IIRC) and improved spec implementation. Most firmware updates for the RN modules on thenet (and Forum) will assume your are on an ‘a’ but believe Google may cover some uplifts for the earlier implementation. The Things Uno was also a Leonardo derivative with a RN module but I never bother tryng to get old 83’s running on V3, especially with early rev firmware, only with 83A’s… just my 2 cents…YMMV!

(Believe IoT Academy may have moved to an alternate module for later Marvin based Education/trials kits…)

I’ve got a node with RN2483 with earlier firmware happily running on V3 continuously since may ‘21. No problem at all.
Your stock of The Things Nodes all contain 2483, not A modules as well.

If the RN2483 has at least firmware 1.0.1 it can be updated to 1.0.5 using a serial connection. Lower firmware levels require a microchip programmer connecting to the module because the boot loader requires updating as well.

The principal is the same for V3 as it was for V2. Create an application, add the device using the build in DevEUI and Join-/AppEUI all zeros or a generated one (search the forum for an EUI generator)
Use LoRaWAN specification 1.0.2, Regional Parameters 1.0.2B.
Always use OTAA.

Hints/remarks in last week most enlightning: Thanks!
:wink: Jac’s latest messages further extend my required learning curve, because all “Martin’s” in (old) stock have RN2483 as marker on the chip, and dating from before 2020:
have a Pickit3 at hand, know how to use, and upgrade of the firmware an interesting challenge,
but not as a starter for a novice for a LoraWAN setup. Just addition of risc.

For a starting configuration for a shorter learning curve perhaps better to look for some uptodate, general device like LHT65,
after info from Dragino on the possible status of the LPS8Gateway:
waiting for that info before proceeding with making 1 functional chain of elements without basic errors …

Addition Feb07,2023:
Found an active Gateway at a distance of approx. 800m.
Not as favourable as ‘own Gateway’, but might be usable for a 1st experiment,
while waiting for reaction from Dragino …

Hi Jac your right as always as it’s more a specific firmware rev issue than just the module type. My comment was generic wrt 83’s. I had some very early systems (2015 & 2016 build modules IIRC) where the issues arose… seem to remember e.g. V4 (tweetoniq?) ‘white’ build UNO’s used and again IIRC sure they had <rev 1.0 firmware… 0.95?, also I had 83’s on break out boards that struggled on generic Leonardo bds (that Uno based on) where the 83A were fine… likely with later firmware and none of the SF related reliability Issues…… all seems a long time ago now.

Out of curiosity I double checked and the Things Nodes I have in stock are indeed 83A’s :slight_smile: as I thought not 83’s as you suggest…. My UNO’s all look to be 83’s but with 1.0.5 I believe. Of course IIRC Nodes not Leonardo based in the way the Uno is (Sparkfun based instead?).