Feat/add streamhelper

[senslab-MarkHawkins]

Added driver to handle sensors streaming serial data on a dedicated port. Steam configuration (headers) can be configured in the UI and appropriately update state and UI elements. A helper library was created to calculate stats on a data stream which can be reused in other projects.

[nkleiner]

It looks like you committed a copy of the packaged driver itself with your changes. We avoid doing this to keep the repo from getting bloated with packaged versions of drivers, instead we rely on the pipelines that care about the drivers to package them at runtime.

[nkleiner]

The existence of the "StreamHelper" library here is a bit of an oddity. The device driver repo should really only contain the drivers themselves. I think there's two options for how to approach handling the stream helper library:

1. If we think this is a pretty universally helpful set of tools, then perhaps it belongs in either it's own dedicated tool library or maybe as part of one of the existing toolkits (such as the serial toolkit perhaps?)
2. If this is really only useful to the device you've created here, then it should probably just live there as a set of static calls for that device to use

I'm open to either as a solution, but definitely don't think it should linger as its own project in this repo

[senslab-MarkHawkins]

I was thinking a reusable toolkit would probably be appropriate. Mostly I wanted to get you some example code and show any interested parties outside contributions. For long-term it really depends on the timeline for device-to-device communication. If a device can subscribe to another's feed, then streamhelper becomes obsolete really fast. The new signal processor would be completely appropriate as a driver. If that is further down the road, then streamhelper as a toolkit would be nice. With the caveat that this class could be expanded significantly (to include band-pass filters, FFT analysis, etc). After working with ARES a bit, being able to do the real-time stats makes our experiment setup sooo much easier. Aaron

…

________________________________ From: Nick Kleiner ***@***.***> Sent: Friday, August 14, 2026 8:14 AM To: AFRL-ARES/Ares.Device.Drivers ***@***.***> Cc: Mark Hawkins ***@***.***>; Author ***@***.***> Subject: [EXTERNAL]Re: [AFRL-ARES/Ares.Device.Drivers] Feat/add streamhelper (PR #3) You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [EXTERNAL] This email originates from outside AV. Do not click links, open attachments, or provide credentials unless you recognize the sender and know the content is safe. [https://avatars.githubusercontent.com/u/103515522?s=20&v=4]nkleiner left a comment (AFRL-ARES/Ares.Device.Drivers#3)<#3 (comment)> The existence of the "StreamHelper" library here is a bit of an oddity. The device driver repo should really only contain the drivers themselves. I think there's two options for how to approach handling the stream helper library: 1. If we think this is a pretty universally helpful set of tools, then perhaps it belongs in either it's own dedicated tool library or maybe as part of one of the existing toolkits (such as the serial toolkit perhaps?) 2. If this is really only useful to the device you've created here, then it should probably just live there as a set of static calls for that device to use I'm open to either as a solution, but definitely don't think it should linger as its own project in this repo — Reply to this email directly, view it on GitHub<#3?email_source=notifications&email_token=CKE5IRUACV2DWJVXO5A2COD5J37BDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZGMYTKNRRGAZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5293156102>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/CKE5IRRGFHVMPN7CR4KJCET5J37BDAVCNFSNUABGKJSXA33TNF2G64TZHMYTCNZZHEZTMNJQGM5US43TOVSTWNJQGU2DGOJYGQ3DTILWAI>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/CKE5IRQ33GVYWNGSQJ2RXMD5J37BDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZGMYTKNRRGAZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/CKE5IRRXQZKCABPWW7MPQL35J37BDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZGMYTKNRRGAZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[nkleiner]

I gave it some thought, and I think this has a place in the Ares.Toolkit.Device library specifically. My suggestion would be taking the stream helper class and adding it to a new "Ares.Toolkit.Device.Telemetry" namespace. This means we can continue to re-use this logic across devices while also giving a clear path forward for creating additional telemetry focused helper classes which seems likely.