Just wait for the SDK + documentation which should be available later that year.

Zitat von »Shoggy«

Just wait for the SDK + documentation which should be available later that year.

I second the request for Aquaero 5 documentation for the purpose of adding Linux support (currently looking to make some enhancements to aerotools).

Shoggy, do you have an ETA what month we can expect this?

Around the end of this year.

We will not offer any Linux tools. Please note that the already existing Linux tools were programed by users.

Zitat von »Shoggy«

Around the end of this year.

We will not offer any Linux tools. Please note that the already existing Linux tools were programed by users.

Thanks for the clarification. Looking forward to details on the USB protocol.

As with many consumer grade hardware products we Linux users are often left swinging in the breeze support-wise, but with adequate info we make due on our own.

Hi Shoggy,

Any chance for an early Christmas present? hint, hint

I have made quite a bit of progress on deciphering the contents just by inspecting what my modified version of aerotools returns, but documentation/reference code would make things far easier given the significant differences between the Aquaero 4 and Aquaero 5.

Will not be available within this year.

Zitat von »Shoggy«

Will not be available within this year.

Bummer... So are you thinking January, or will it likely be later?

I can not tell. Also possible that it will be later.

We are still working on the SDK for Windows.

I had a look on the overclock forums. The names of the fans/sensors are not in the same report as the data. Its seperated to reduce the amount of data which has to be transfered at any sensor read out. Also the aquaero 5 uses special reports for reading/writing to the external flash memory in the dataflash. It's much more complicated then the aquaero 4 structures as for any dataflash related actions you have to send an request with one report and then you can read out the result, which is the same with the names for the fans and sensors which are also stored in the dataflash.

In general we are asking the aquaero for a memory bump at a specified dataflash address. It's clear that not all areas of the daflash are allowed to read or write but you can damage the memory with a wrong write command. if the aquaero has read the area it can be read out with a USB-report. After that you still need to know about the structure of the memory to allocate the names to the fans/sensors.

Zitat von »Stephan«

We are still working on the SDK for Windows.

I had a look on the overclock forums. The names of the fans/sensors are not in the same report as the data. Its seperated to reduce the amount of data which has to be transfered at any sensor read out. Also the aquaero 5 uses special reports for reading/writing to the external flash memory in the dataflash. It's much more complicated then the aquaero 4 structures as for any dataflash related actions you have to send an request with one report and then you can read out the result, which is the same with the names for the fans and sensors which are also stored in the dataflash.

In general we are asking the aquaero for a memory bump at a specified dataflash address. It's clear that not all areas of the daflash are allowed to read or write but you can damage the memory with a wrong write command. if the aquaero has read the area it can be read out with a USB-report. After that you still need to know about the structure of the memory to allocate the names to the fans/sensors.

Thanks Stephan,

This is very useful info!

I am most interested in reading the data out and fully understand the risks of writing to the wrong address. Can you give me a pointer/reference to the (read) report commands for the dataflash and the valid address ranges in which the data lies?

Zitat von »JinTu«

Can you give me a pointer/reference to the (read) report commands for the dataflash and the valid address ranges in which the data lies?

no, not at this moment.
The data protocol to read the flash memory is not easy. when we finished the sdk, a code sample to read memory locations we include into the sdk.

Zitat von »sebastian«

Zitat von »JinTu«

Can you give me a pointer/reference to the (read) report commands for the dataflash and the valid address ranges in which the data lies?

no, not at this moment.
The data protocol to read the flash memory is not easy. when we finished the sdk, a code sample to read memory locations we include into the sdk.

Thanks for your reply Sebastian,

Looking forward to the SDK release.

Starting to dig into this after seeing the thread over on the main German forum.

From a USB capture on one of my Windows boxes running Aquasuite:

I discovered this past weekend that the original aerotools author lynix has started a new project for supporting the Aquaero 5 on github by the name of aerotools-ng . The author has chosen to utilize the HID functionality of the Aquaero 5, and the hidraw capabilities of the Linux kernel (removing the need for libusb or any other external dependencies.) Aerotools-ng has a long way to go before it will be as full featured as the original aerotools, but it does appear to be under active development

I have started making some enhancements and have already sent the first of what will likely be many pull requests.

Zitat von »JinTu«

Starting to dig into this after seeing the thread over on the main German forum.

From a USB capture on one of my Windows boxes running Aquasuite:

Quellcode

1 2 3 4 5 6 7 8 9 10

[288 ms] UsbSnoop - FilterDispatchAny(a44ddfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL [288 ms] UsbSnoop - FdoHookDispatchInternalIoctl(a44de1ea) : fdo=88bbfe18, Irp=88bd0e70, IRQL=0 [288 ms] >>> URB 6 going down >>> -- URB_FUNCTION_GET_DESCRIPTOR_FROM_INTERFACE: TransferBufferLength = 000000ec TransferBuffer = 88ba6430 TransferBufferMDL = 00000000 Index = 00000000 DescriptorType = 00000022 (illegal descriptor type!) LanguageId = 00000002

Quellcode

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

[295 ms] UsbSnoop - MyInternalIOCTLCompletion(a44de126) : fido=00000000, Irp=88bd0e70, Context=83ad24d8, IRQL=2 [295 ms] <<< URB 6 coming back <<< -- URB_FUNCTION_CONTROL_TRANSFER: PipeHandle = 88bddb70 TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) TransferBufferLength = 000000ac TransferBuffer = 88ba6430 TransferBufferMDL = 83708190 00000000: 06 00 ff 09 01 a1 01 85 01 15 00 26 ff 00 75 08 00000010: 96 92 02 09 01 81 02 85 03 15 00 26 ff 00 75 08 00000020: 96 07 00 09 01 81 02 85 04 15 00 26 ff 00 75 08 00000030: 96 41 08 09 01 91 02 85 05 15 00 26 ff 00 75 08 00000040: 96 04 00 09 01 91 02 85 06 15 00 26 ff 00 75 08 00000050: 96 04 00 09 01 91 02 85 07 15 00 26 ff 00 75 08 00000060: 96 10 00 09 01 91 02 85 08 96 40 08 09 00 b2 02 00000070: 01 85 0a 15 00 26 ff 00 75 08 96 1b 00 09 01 91 00000080: 02 85 0b 96 7b 09 09 00 b2 02 01 85 09 15 00 26 00000090: ff 00 75 08 96 0b 02 09 01 91 02 85 0c 15 00 26 000000a0: ff 00 75 08 96 0b 02 09 01 81 02 c0 UrbLink = 00000000 SetupPacket = 00000000: 81 06 00 22 02 00 ec 00

Making some progress in getting the reports in Linux. It looks like some of the reports have changed counts since earlier firmware versions compared with drdeath's post on the main German forum. Here is an annotated report descriptor dump from my Aquaero 5XT:



I have only just gotten started interpreting the report contents, but progress is always a good thing...

FYI for anyone interested, lynix and I have been chugging along deciphering the Aquaero 5 HID reports.

We already have a significant portion of (input) report ID 1 (sensor readings) figured out and have added support for everything in aerotools-ng. Progress on the other reports has been slow, but I have the first portion of (feature) report ID 11 (settings) figured out.

Thus far lynix and I have managed to locate and add support to aerotools-ng for the following:

HID input report 0x1

• current time
• serial number
• firmware version
• bootloader version
• hardware version
• uptime
• total time
• temp sensors
• fan VRM (amp) temp sensors
• CPU temperature sensors
• flow sensors
• level sensors
• fan (RPM, duty cycle, voltage, current)

HID feature report 0xB (11)

• language setting
• info page settings
• temperature units setting
• flow units setting
• pressure units setting
• decimal separator setting
• temperature sensor offset settings
• fan VRM (amp) temperature sensor offset settings
• CPU temperature sensor offset settings
• fan settings (min RPM, max RPM, min duty cycle, max duty cycle, startboost duty cycle, startboost duration, pulses per revolution, control mode, data source, programmable fuse setting)

I also managed to add a few more enhancements to make better use of the sensor data. One big one is exporting the sensor data to SNMP, so you can use your favorite NMS or graphing utility for threshold alarms and graphs. Here are a few sample graphs from my Cacti template using this data:

It certainly does take more time doing development without documentation or references. The Aquaero 5 equivalent of AquaComputer.TranslationClasses.aquaero_Rev4.cs from the SDK or an equivalent header file with the enums would be very handy

Dare I ask again for an ETA on the long awaited SDK?

Hi folks,

Another Linux user recently sent me a set of captures from USBPcap which yielded a treasure trove of new info for how the Aquaero5 communicates with Aquasuite. Thanks to this info, I have added support for setting software sensor values (via HID report 7) to my master branch of aerotools-ng on github. I am now in the process of adding support for setting the time (via HID report 5), setting device names (via HID report 10), and reading the device names (a combination of HID report 9 and 12).

I also see HID report 6 on the wire, but haven't figured out what it is yet. Some samples of what I have seen:



Note: the first byte is the report number (06).

Stephan and sebastian can you tell me what HID report 6 is and how it is being used in the examples above?

Do not use Report 6, this report control the device, lock unlock, reset, and other things. When you send wrong data, the device can be corruppted.