Hello,
My team is working on integrating a SAMI-pH logger (SAMI-pH) with the spotter buoy.
We are exploring the casket mount and would welcome the opportunity to discuss the design.
2 Likes
Great question!
Because this payload is pretty big we may have to get creative about mounting.
@estackpole do you have any ideas on the approach? I think the diameter is a bit bigger than the BMDK’s standard mount?
~Z
@Taylor.gill This is a cool project! Where in the water column were you hoping to mount this (e.g. close the surface, close to the bottom, mid-water at x depth?) As @zack_j suggested, I’m not sure if a normal casket would be the right device for mounting this (it’s quite a bit smaller than the dimensions of the sensor), but we’ve been working on some other designs that could fit the bill. Are there any other important constraints to consider for assuring the sensor gets good data?
Hi @estackpole, the sensor will have to be placed on or near the bottom since we hope to obtain samples from there. Ideally, we would like to have its location be permanent and on the seafloor, while still maintaining connection with the buoy.
One idea we are exploring is a bi-mooring. We believe this would help with stability of the buoy and allow for our sensor to be moored on the seafloor.
Please let me know if you have any thoughts on this.
@Taylor.gill I think you’re on the right track with the bi-mooring idea! I love the stability of a system like that. You’ll need to consider deployment and retrieval strategy, stability on whatever bottom type you have, and assurance that the smart mooring cable or any chain coming from the primary mooring isn’t able to interfere with the sensor mooring. In general, were you thinking of something like this?:
1 Like
Hi @estackpole,
We were thinking of having a shackle plate at the end of the buoy node and two chains mooring it to anchor pins. We have a larger buoy moored similar to this.
We would like the sensor to be on the seafloor if possible. This means we would need the node to sit low enough in the water column and possibly create a longer connection chord.
What do you think about this approach?
1 Like
seems like a good candidate for integrating with a new low cost, low power, and subsequently low throughput acoustic modem like the water linked units. then a motion sensitive, microfluidics sensor like this can standalone peacefully and allow a smart mooring to still have a torque shedding rotational mechanism at the mooring block. sami recovery could be done using a timed unit from nortek (eco), or acoustic release from edgetech, innovasea etc.
as an aside: may i ask the reason/need for realtime pH?
1 Like
I’m worried that there will be too much torsion in the mooring line built up from the top section rotating in the tides/wind. This can really twist up the yellow data cable quickly.
There’s some prior art to this we did a while back for the pressure sensors but it is a bit outdated…
If it were possible, I would rather see the SAMI as big as it is, mounted on the line above a rotational element.
Something like this:
Where the SAMI takes the place of the red RBR at “D”.
One thing of concern if we go this route is that the SAMI is significantly larger than the original design for the casket mount. @estackpole I was wondering if you had any objections to helping us think this design through or if you think we need to keep iterating on the seafloor mounted or two element designs mentioned in this thread previously.
Z
Hello!
@zack_j @evan @zachary I wanted to give a little update on our project and ask some new questions. We have successfully integrated the pH logger and are now working to parse the information coming through the API.
Can you please help me to understand what I am exactly seeing in my API? Is this buoy data or just the integrated instrumentation? Do you have any information on the best way to parse the buoy data if this is included?
Let me know if it would be helpful to see some of the data coming through.
Please advise.
Best,
Taylor
Good question Taylor!
Referencing Guide 5 retrieving the data is covered in “04. Accessing data remotely over the Sofar API”
The sensor-data looks like this:
Using curl or wget the data you input for tx should be under “value” there. In the photo this would be the string of hex starting with “7700…” If you are seeing data differently than you expect please share the code you are using to send data as well as the data received from the API so we can dig into it with you.
TIP: Don’t forget about start date and end date for specific historical message queries.
TIP: I’m not the biggest power user for command line curl commands so I like to employ one of the following tools:
- Postman. Download Postman | Get Started for Free
- The Aqualink API tool. https://bristlemouth.aqualink.org/
Buoy data is retrieved separately from Bristlemouth node data. The API use is covered here: Spotter Data - Sofar API
Does this help answer your question? Were you able to make sense of the data you are receiving? Post some example text with context if you’d like to dig a little deeper.
Z
Hi @zack_j !
Thank you for the info. As an example this is what it looks like when we open up our API.
{“status”:“success”,“data”:{“spotterId”:“SPOT-31260C”,“messages”:[{“momsn”:null,“transmitTime”:“2024-01-29T19:03:31.000Z”,“approxLon”:“-80.16”,“approxLat”:“25.73”,“cep”:null,“message”:“dd65b7f67ce258a8020cf0cd616d40984303b6675d32dbfb3e09deee2700000000040441”,“createdAt”:“2024-01-29T19:03:46.250Z”,“messageHeader”:221,“counter”:null,“partNo”:null,“processed”:true,“commSource”:“cellular”,“processingSource”:“embedded”},{“momsn”:null,“transmitTime”:“2024-01-29T19:17:41.000Z”,“approxLon”:“-80.16”,“approxLat”:“25.73”,“cep”:null,“message”:“dc65b7f9d6de01b0021ce8cd614d40981383b6675d0819a5c912c320803b0017a1403c080bb99460f1b589627100000c372d0d2c8a0c03ac6103a074898c64c79664b001e1f424507801f401dbe800000000000000030034ceb17feecaca51c20190c70c454000c181d81f401d80e81e03844012c2454040003848221394e108489ce529d5909c63184e10842528ca8b3e”,“createdAt”:"2024-01-
This looks pretty good to me…I’m going to see if I can get another set of eyes on it but I think the raw data is contained after "message":" in this case dc65b7f9d6de01b0021ce8cd614d40...
I would hope that this is the raw data that you intended to send.
What, for my own benefit, was the command you used? (please mark out the API Key).
Thanks!
You’re on the right track, but that looks like a different Spotter health and configuration message because it starts with dc. As mentioned here you should look for messages that start with de. Your content in such a message will come after a 29-byte header.
1 Like
I concur with @zack_j – it looks like the data is getting through well. The next steps are to continue working with the Dev Kit Guides to learn how to parse these messages. (edit: and please have a look at @zachary 's response above about the different message types.)
Please see the respective conclusions of sections 03c and section 4 in DevKit Guide 5. There are decoders for the message payloads here.
Please let us know if we can help further.
Thanks,
Tim
Thank you all!
I have 2 follow up questions.
I see this: {
“data”: {
“spotterId”: “SPOT-31260C”,
“limit”: 500,
“waves”: [
{
“significantWaveHeight”: 0.91,
“peakPeriod”: 17.06,
“meanPeriod”: 12.24,
“peakDirection”: 258.001,
“peakDirectionalSpread”: 64.479,
“meanDirection”: 261.819,
“meanDirectionalSpread”: 67.351,
“timestamp”: “2024-01-29T19:50:00.000Z”,
“latitude”: 25.7346,
“longitude”: -80.16237,
“processing_source”: “embedded”
},
{
“significantWaveHeight”: 1.95,
“peakPeriod”: 25.6,
“meanPeriod”: 18.78,
“peakDirection”: 356.847,
“peakDirectionalSpread”: 71.054,
“meanDirection”: 330.887,
“meanDirectionalSpread”: 73.067,
“timestamp”: “2024-01-29T20:20:00.000Z”,
“latitude”: 25.73443,
“longitude”: -80.16232,
“processing_source”: “embedded”
}
],
“wind”: [
{
“speed”: 0.8,
“direction”: 188,
“seasurfaceId”: 1,
“latitude”: 25.7346,
“longitude”: -80.1623667,
“timestamp”: “2024-01-29T19:50:00.000Z”,
“processing_source”: “embedded”
},
{
“speed”: 1.2,
“direction”: 45,
“seasurfaceId”: 1,
“latitude”: 25.7344333,
“longitude”: -80.1623167,
“timestamp”: “2024-01-29T20:20:00.000Z”,
“processing_source”: “embedded”
}
]
}
}
Is there a way to expand the 500 limit? What if I wanted to see all of the recordings from 1 day? Additionally, does the spotter need to have the temperature probe connected to a node to report sea surface temperature?
Hey Taylor, the limit is 500.
If you need to pull longer historical data, you can create a script to divide a start date and end date into segments. A good rule of thumb is 7 days of data at a time.
Regarding SST, the standard Spotters have the sea surface temperature, for the Smart Moorings the SST is replaced by the Bristlemouth connector which leads to a sensor (or more) of your choice which can include a temperature sensor on the first (surface node).
~Z
In this case, please experiment with using a startDate of the date you’re interested in, and an endDate of the date afterward. For example:
startDate=2024-03-01&endDate=2024-03-02
And please remember that the sensor data does not get delivered through the /wave-data endpoint. The sensor data only gets delivered through the /sensor-data endpoint.
Thank you all so much for your help with this we were able to get our parsed data.
Follow up question.
We are going to modify our dev kit and drill a hole through the off hand endcap (the one that doesn’t have the bristlemouth passthroughs). Does anyone have advice on how best to do this and make sure our set up is waterproof?