Nesting data field (example: Stryd data field into another connect iq data field)?

Thank you jim_m_58, would an alternative to build an application? Is it possible to use a CIQ Df from someone else into an application?

At this time you can't embed any type or combination of Connect IQ applications within each other. Also, as jim_m_58 mentioned, you can't get access to the data that Stryd is maintaining as part of it's application. You're going to have to make some sort of decision about what data is most important during your activity and that you want data wise for analysis afterwards and choose which fields you use accordingly.

Would it be possible to build a connect iq field that would display the Stryd data field?

I queried Angus a few months ago, it's not so easy... here is his reply to my inquiry:

Hi Peter,

Thanks for reaching out to me!


There is a challenge with this. I will explain the situation. I do not think we can work around this, but maybe you can find something I missed.

Stryd is a running power meter. There is not a running power meter ANT+ channel at the moment. Therefore, we have a custom ANT+ channel that sends the running power data to the watch.

We have a Stryd Power data field that connects on this custom ANT+ channel and records all of the Stryd data to the FIT file. This data field uses the full amount of memory available (16KB).

I could provide the custom ANT+ channel information to you. You would add it to your data field and be able to show the power.

There are two constraints here:
1. Communication: The watch can only create one ANT+ connection per channel (same channel, same device). The watch will crash if the user tries to use your data field and the Stryd Power data field. So, they will have to opt to only use your data field.
2. Memory: If they opt to use your data field, they will not be able to record data to the FIT file. You can add the FIT recording to your app but you would essentially add another 8-10KB of memory to your add, which would be hard to do given the constraints.

Problems:
1. The user would have to give up data recording.
2. The user may experience watch crashing if they added both of our services.
3. There are memory/ecosystem constraints that prevent us from reaching an ideal solution.

What is the best option then?
I recommend that the user adds two data fields to the run mode on their watch.
1. Stryd Power. This lets them view and record the power and the other metrics.
2. Peter's Pacer. This lets them get all the great pacing features from your app.

This is the problem I am seeing right now. I would gladly help you get this running and I think it would be very useful for the user. However, I suspect that this would cause trouble/confusion for the user if they are not able to use this as they intend to. It is possible I am missing something here. Do you see any way around this or an avenue I am missing?

Best,
Angus

Hi peterdedecker, thank you for the reply. This is exactly to use something like your datafield that I was asking. I understand the limitations.

If we were to think outside the box... If I remember correctly we could use the cadence field to display the power from the Stryd. Is it possible to have 2 cadence channel? By that I mean, the cadence sensor in my HRMrun strap + add the Stryd as another cadence pod? Just thinking ;)

well to be honest my communiciation with Angus proceeded a bit after the initial mail, you see both my mail slightly indented as Angus' his answers.

Hi Peter,
We would indeed need to avoid that it would make it crash for the
user, I didn't realise it would be so complex to add the connection to
your power meter.

Yes. I plan to talk to Garmin when I can advise a good system. There would need to be some way to stream data across apps. I need to think of a system that would have utility outside of my use case and be simple. I am not sure on this part yet. It was my intent to only show the power value, reimplementing all the
other logic you already have made would simply not fit in my
datafield.
Yes. I totally understand. I also don't see an immediate solution that would not have the
problems you describe, but perhaps a solution for a next version of
your stryd device could be to not use a custom channel but to transmit
over the Sensor.SENSOR_BIKEPOWER channel... then I think...subscribing
to Sensor.SENSOR_BIKEPOWER events would allow for 3rd party apps to
get the info.currentPower...

I have good news on this front. It is possible to do this right now. We do broadcast as a bike power meter. You can use info.currentPower to achieve this if the user connects Stryd as a bike power meter. This limits usage to the watches that support bike power meters (920/F3/735), but it will work.

This is possible. Personally, I would still tell the user 'No' on this feature request. This solution is not elegant. It is not very flexible as it only works on a subset of watches. Additionally, it adds a lot of conditional logic on your side and a more complicated user manual for the user.

Overall, you have found a way to make it work! But, it may be more trouble than it is worth and and may not benefit this specific customer if they do not have the right watch. Is it ok to forward your feedback to the user that asked the question?

Yes.
Best,
Angus

as you can see setting it to transmit as a bike_powermeter would be a viable option for the devices that support it.

Thank you!