Author Topic: Hacking the HDO1k/HDO4k Rigol 12 bit scope  (Read 181878 times)

0 Members and 10 Guests are viewing this topic.

Online mawyatt

  • Super Contributor
  • ***
  • Posts: 3502
  • Country: us
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #325 on: December 12, 2022, 03:17:27 pm »
2N3055 you bring up a good point, the hardware price point is indeed very attractive. However, without the followup firmware support, the full potential of this hardware can not be realized.

With a true core 12 bit ADC, good noise performance front end, and high resolution display, Rigol certainly has a good baseline hardware platform to move forward from. We found the screen captures from the remote interface as shown very attractive, showing the benefits of the core architecture with higher resolution display capability.

Also agree, Rigol seems to have an early release regarding firmware maturity state, and why we've chosen to wait and see. Recall in Dave's teardown a multi-wire connector (red wires) that appears to be hand assembled wire-by-wire rather than machine created from a multi-wire cable, likely from a common connector error where the pins get swapped. Wager we'll see later versions with the usual multi-wire machine created cable assembly!! 

We have a need for a higher core resolution ADC based DSO, which earlier was partially fulfilled with the Picoscope 4262, but dislike PC based scopes of any kind and don't have the room on our crowed bench for a laptop. As good as the 4262 is, it hardly ever gets used because too much of a hassle to get hooked up to a laptop, boot-up, select application and so on...just prefer a stand along solution. Since our main project is on hold at the moment we have some time to wait and see.

Best, 
« Last Edit: December 12, 2022, 03:28:08 pm by mawyatt »
Curiosity killed the cat, also depleted my wallet!
~Wyatt Labs by Mike~
 
The following users thanked this post: 2N3055, Bad_Driver

Offline markone

  • Frequent Contributor
  • **
  • Posts: 730
  • Country: it
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #326 on: December 12, 2022, 04:58:35 pm »
... It clearly was rushed to market...

We can see this. They have things to polish.
Color grading is not so grading. Only red and yellow.
Sometime capture stop when you run through the timebase. (RUN/STOP button became red).
The are bugs to be reported but they need to be well documented.

I saw worse launch FW release, but i would say it's time to release an update, for sure removing serial decoder crash, quieter FAN profile and so on.

So, if RIGOL is reading this, please ACTION !

LOL.. Good luck with that.
Rigol HQ is shaking in fear...

-snip


Of course I was joking, i have gray hairs and I know quite well how things work, in general.

I was also aware that, as you said, Rigol will take its time to meet a decent level of FW stability, as many other brands, I would be much more pissed of in case of hardware defects.
 
Anyway, right now I'm working with the HDO1K with a current clamp and a differential probe on a power inverter circuit, I can spot a huge difference in signal details versus MSO5000, usability is way better, screen readability is way better, measure system is better and so on.

I would say I am satisfied regardless any other consideration, especially thinking that the alternative for a 4ch 200MHz 2GS/s 100Mpts (after "free" upgrade) would have been waaay more expensive (3x).   
 
The following users thanked this post: 2N3055

Online Martin72

  • Super Contributor
  • ***
  • Posts: 6251
  • Country: de
  • Testfield Technician
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #327 on: December 13, 2022, 11:13:45 pm »
Siglent knows how to get the maximum out of the hardware softwarewise, rigol builds it´own hardware but have lacks to get the horsepower on the street, softwarewise.
What if they would someday work together, it would be a nightmare for other brands.
Sigol....Riglent... ;D
"Comparison is the end of happiness and the beginning of dissatisfaction."
(Kierkegaard)
Siglent SDS800X HD Deep Review
 
The following users thanked this post: egonotto, Bad_Driver

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28887
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #328 on: December 13, 2022, 11:14:31 pm »
Siglent knows how to get the maximum out of the hardware softwarewise, rigol builds it´own hardware but have lacks to get the horsepower on the street, softwarewise.
What if they would someday work together, it would be a nightmare for other brands.
Sigol....Riglent... ;D
Go wash your mouth !  :horse:
Avid Rabid Hobbyist.
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Online Martin72

  • Super Contributor
  • ***
  • Posts: 6251
  • Country: de
  • Testfield Technician
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #329 on: December 13, 2022, 11:15:16 pm »
 :-X :-DD
"Comparison is the end of happiness and the beginning of dissatisfaction."
(Kierkegaard)
Siglent SDS800X HD Deep Review
 

Online mawyatt

  • Super Contributor
  • ***
  • Posts: 3502
  • Country: us
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #330 on: December 13, 2022, 11:32:28 pm »
Honeywell and Fairchild merged awhile back but couldn't decide which name to use, so they used both.

Fairwell Honeychild  :-DD

Best,
Curiosity killed the cat, also depleted my wallet!
~Wyatt Labs by Mike~
 
The following users thanked this post: hexpope, egonotto, 2N3055, Martin72

Offline oliv3rTopic starter

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #331 on: January 03, 2023, 08:04:22 pm »
Siglent knows how to get the maximum out of the hardware softwarewise, rigol builds it´own hardware but have lacks to get the horsepower on the street, softwarewise.
What if they would someday work together, it would be a nightmare for other brands.
Sigol....Riglent... ;D

But that's a management problem. Look at how they've been 'dicking around' the last decade(s). I mentioned this elsewhere, but they have the old blackfin system, running some custom software (not something high-level like FreeRTOS or linux).

So then they went to the Xilinx Zynq solution, and started playing with Linux and QT. Now, as any software engineer will tell you, humongous effort, will take years of development, and basically means 'throw away most of the stuff and knowledge you have and start again'.

Now, I do not blame them here, it was a good idea to be fair. Using more 'off the shelf' and high level software is good, develop a strong 'platform' for yourself, and evolve that.

There where some ugly things with their first attempt, and they did kind of try. They supported 3 scopes with the same stack (MSO5000, DS7000 and MSO8000).

So then they introduced the vector analyzers, more or less based on the same platform. But, one could already see, that it was a different team that was working on this, as there where already some differences that where not logical (stick with a single platform!).

Anyhow, the next thing that happened, is your typical crappy software development rodeo, release new software for system A, don't touch B, do something else with C. E.g. your software starts to diverge for the different products. Not a good idea, if you want to keep it a platform.

So then, the MSO80000 came, I haven't looked at the software, but afaik it is based on the Zynq ultrascale. Now, with proper engineering, you can build your platform with different underlying hardware. So this should have not been a problem, anyway.

Fast forward a bit, the new HDO1000/HDO4000. New chip (Rockchip), which is not bad per say, you can still do the platform thing, but then also android based. While that is a stupid design choice, it's a choice. Maybe they only had java/app developers available. Anyway, it basically does mean YEARS of development effort all over again!

But wait, there's more. The new DP831 (or whatever number it has) powersupply is based on a different SoC yet again. So, again, more effort. I haven't checked the software, might run Android, but the UI might be to simple? Idk, maybe it's on QT again. Who knows.

Case in point, this wastes a shit load of developer years. Yes a platform costs more effort initially and it costs effort to keep it neat and clean, but surely not as much as having to deal with all these different platforms.

Also, software updates. You think the Android developer working on the HDO1000 can easily fix a bug on that MSO8000? Of course not (though any developer worth their weight should be able to of course0. It DOES cost extra time and effort to fix stuff. Now, you can argue that us hackers that pay 350 for a scope shouldn't think we deserve software updates, but what about that 20k MSO8000? Exactly. Also, adding features platform wide, also keeps your existing cusotmers happy.

Some loss in sales because software feature A only exists on the latest and greatest? Sure. But also fixing a bug, fixes it everywhere.

Anyhow, this is me just ranting in frustration, as this can be prevented with good managers that understand this, and control this and think big pictures/long term, and not just 'release day was yesterday, wtf ship it already'.

Offline markone

  • Frequent Contributor
  • **
  • Posts: 730
  • Country: it
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #332 on: January 04, 2023, 01:44:47 am »
-snip
Also, software updates. You think the Android developer working on the HDO1000 can easily fix a bug on that MSO8000? Of course not (though any developer worth their weight should be able to of course0. It DOES cost extra time and effort to fix stuff. Now, you can argue that us hackers that pay 350 for a scope shouldn't think we deserve software updates, but what about that 20k MSO8000? Exactly. Also, adding features platform wide, also keeps your existing cusotmers happy.

Some loss in sales because software feature A only exists on the latest and greatest? Sure. But also fixing a bug, fixes it everywhere.

Anyhow, this is me just ranting in frustration, as this can be prevented with good managers that understand this, and control this and think big pictures/long term, and not just 'release day was yesterday, wtf ship it already'.

I agree with what you said but there could be another reason behind the Rockchip move : they probably are shifting toward a full China made HW architecture, after the ASIC for ADC and frontend sections the SOC was the most likely to be changed.
 

Offline dreamcat4

  • Frequent Contributor
  • **
  • Posts: 495
  • Country: gb
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #333 on: January 04, 2023, 08:53:59 am »
not trying to read too much into this but...

from a kernel support / hardware support and drivers perspective. The manufacturers of all these chinese ARM socs they all always only bother to write and release drivers for android operating system.

That is to say: for all those dedicated IP blocks within the soc itself, including for the GPU hardware acceleration etc.

Maybe some vendors will "pretend" to care about porting over to linux kernel. However by the time that is done might be well after the SOC is anymore relevant in current production, that soc is usually discontinued from curent manufacture (by then) and replaced with a shiny newer soc for the next wave of products.


So if i had to guess, this was the reason why Rigol felt going for android here. And I don't actually have any clear or satisfying answer what other good options they had. Once you realize that they aren't going to have much sway with rockchip, or money to pay rockchip for developing linux drivers (for said soc), or much money for soc, (or to change for other soc which isn't dirt cheap).

Maybe it's necessary to do some sort of a numbers calculation / estimations to determine which cost is greater. Paying for more expensive soc versus paying more money for software developers to redevelop on android platform. And be switching platforms. Which may also depends how they structured their software stack etc.

But the other thing would be the relative SoC availability in china. If they cannot get any other decent socs due to supply chain shortages. Or guarantee supply. Then that would not work, you complete a product to ship a product without any cpu in it.

I do agree about their software being really bad however. It's just not good enough in its current state. And they have this long history of just moving on to next shiny new thing. And then just never fixing what was un-shippable to begin with on their previous product. Just not on.

Maybe other people here have better knowledge than me about the situation with those rockchip socs. And the hardware / drivers support for linux. I was just stating how it's always been with so many chinese arm socs (made primarily for android platform). Yes they might ship linux distro images for them. And then you fire it up, there's no GPU acceleration (that is the main thing).

Perhaps it's because the GPU hardware block is under seperate proprietary IP? Then rockchip would not be responsible for a linux driver for that part. (unlike some of other smaller fixed hardware ip blocks).
 

Online voltsandjolts

  • Supporter
  • ****
  • Posts: 2335
  • Country: gb
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #334 on: January 04, 2023, 10:41:40 am »
We have a need for a higher core resolution ADC based DSO, which earlier was partially fulfilled with the Picoscope 4262, but dislike PC based scopes of any kind and don't have the room on our crowed bench for a laptop. As good as the 4262 is, it hardly ever gets used because too much of a hassle to get hooked up to a laptop, boot-up, select application and so on...just prefer a stand along solution. Since our main project is on hold at the moment we have some time to wait and see.

Put a VESA mount computer on the back of a monitor, doesn't need more space than a standalone.
 

Online mawyatt

  • Super Contributor
  • ***
  • Posts: 3502
  • Country: us
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #335 on: January 04, 2023, 03:36:15 pm »
We have a need for a higher core resolution ADC based DSO, which earlier was partially fulfilled with the Picoscope 4262, but dislike PC based scopes of any kind and don't have the room on our crowed bench for a laptop. As good as the 4262 is, it hardly ever gets used because too much of a hassle to get hooked up to a laptop, boot-up, select application and so on...just prefer a stand along solution. Since our main project is on hold at the moment we have some time to wait and see.

Put a VESA mount computer on the back of a monitor, doesn't need more space than a standalone.

Still need the keyboard & mouse on bench with Picoscope with necessary cables and such which we have no room for. The USB cable with maybe the wireless keyboard and mouse wouldn't be too bad, but we would need to get VESA mount computer which we don't have.

Some folks were discussing putting a VESA mount on not just the PC monitor/computer but the stand alone DSO. This seems interesting as we could use a hefty photographic "C Stand" with a long arm to hold the DSO on the VESA which would suspend the DSO above the bench top but still within reach for adjusting (altho a wireless mouse here would be ideal). Might be something to consider with the Picoscope??

Wish our Siglent DSOs had this VESA mount capability!!

Anyway, thanks for the suggestion :-+

Best,
Curiosity killed the cat, also depleted my wallet!
~Wyatt Labs by Mike~
 

Offline bob808

  • Frequent Contributor
  • **
  • Posts: 281
  • Country: 00
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #336 on: January 04, 2023, 08:38:29 pm »
 

Offline markone

  • Frequent Contributor
  • **
  • Posts: 730
  • Country: it
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #337 on: January 04, 2023, 09:21:45 pm »
You can open a shell through ADB in Windows :

PS C:\ADB_Tool> .\adb.exe connect 192.168.xxx.xxx:55555
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.xxx.xxx:55555
PS C:\ADB_Tool> .\adb -s 192.168.xxx.xxx:55555 shell
rk3399_rigol:/ $ ls /sys/class/thermal
cooling_device0 cooling_device1 cooling_device2 cooling_device3 thermal_zone0 thermal_zone1
rk3399_rigol:/ $

It' possible to display CPU & GPU temps using the following command :

cat /sys/devices/virtual/thermal/thermal_zone?/temp

the scale is mCelsius, in my case they are between 40-45 °C.

I digged a bit in the filesystem looking for temperature set point, I was expecting a configuration file under /etc but this does not seem the case.

Most of temperature related files are under /sys/devices/virtual/thermal/thermal_zone0, here below folder listing :

available_policies
cdev0_weight
cdev1_weight
cdev2_weight
k_i
k_po
k_p
power
cdev0
cdev1
cdev2
slope
trip_point_0_temp
trip_point_1_temp
trip_point_2_temp
trip_point_0_type
trip_point_1_type
trip_point_2_type
trip_point_0_hyst
trip_point_1_hyst
trip_point_2_hyst
cdev0_trip_point
cdev2_trip_point
subsystem
type
mode
sustainable_power
uevent
integral_cutoff
offset
temp
cdev1_trip_point
k_d
policy

where, for example :

trip_point_0_temp = 70000
trip_point_1_temp = 85000
trip_point_2_temp = 115000

It's clear that there is a PID control loop for FAN control that makes use of a PWM peripheral to partialize FAN supply, now it would be nice to find where the target temperature is set, it should be something around 40-45 °C that is too much conservative, setting it higher should decrease FAN speed a lot.

if it weren't for the warranty seal I would have already replaced the original fans with a couple of Sunon 60x60x25, but I would like to try first the "soft" way.
 
The following users thanked this post: thm_w, bob808

Offline bob808

  • Frequent Contributor
  • **
  • Posts: 281
  • Country: 00
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #338 on: January 04, 2023, 09:49:04 pm »
did you check the sys services? if it has systemd then maybe also look in /usr/lib/systemd/
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6981
  • Country: hr
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #339 on: January 04, 2023, 10:27:28 pm »
You can open a shell through ADB in Windows :

PS C:\ADB_Tool> .\adb.exe connect 192.168.xxx.xxx:55555
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.xxx.xxx:55555
PS C:\ADB_Tool> .\adb -s 192.168.xxx.xxx:55555 shell
rk3399_rigol:/ $ ls /sys/class/thermal
cooling_device0 cooling_device1 cooling_device2 cooling_device3 thermal_zone0 thermal_zone1
rk3399_rigol:/ $

It' possible to display CPU & GPU temps using the following command :

cat /sys/devices/virtual/thermal/thermal_zone?/temp

the scale is mCelsius, in my case they are between 40-45 °C.

I digged a bit in the filesystem looking for temperature set point, I was expecting a configuration file under /etc but this does not seem the case.

Most of temperature related files are under /sys/devices/virtual/thermal/thermal_zone0, here below folder listing :

available_policies
cdev0_weight
cdev1_weight
cdev2_weight
k_i
k_po
k_p
power
cdev0
cdev1
cdev2
slope
trip_point_0_temp
trip_point_1_temp
trip_point_2_temp
trip_point_0_type
trip_point_1_type
trip_point_2_type
trip_point_0_hyst
trip_point_1_hyst
trip_point_2_hyst
cdev0_trip_point
cdev2_trip_point
subsystem
type
mode
sustainable_power
uevent
integral_cutoff
offset
temp
cdev1_trip_point
k_d
policy

where, for example :

trip_point_0_temp = 70000
trip_point_1_temp = 85000
trip_point_2_temp = 115000

It's clear that there is a PID control loop for FAN control that makes use of a PWM peripheral to partialize FAN supply, now it would be nice to find where the target temperature is set, it should be something around 40-45 °C that is too much conservative, setting it higher should decrease FAN speed a lot.

if it weren't for the warranty seal I would have already replaced the original fans with a couple of Sunon 60x60x25, but I would like to try first the "soft" way.

CPU could easily be the coolest part on the board... There is still possibility there are chips on the board that are strong point heat source.. An IR photo with thermal camera would be nice to get best insight. If everything on board would be at +20°C over ambient, you would not need fan at all
 

Offline skander36

  • Frequent Contributor
  • **
  • Posts: 783
  • Country: ro
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #340 on: January 04, 2023, 10:49:14 pm »

It' possible to display CPU & GPU temps using the following command :

cat /sys/devices/virtual/thermal/thermal_zone?/temp

the scale is mCelsius, in my case they are between 40-45 °C.


You can see the temperature (CPU, ADC, FE) in realtime on board test section of UI, along with some voltages.
I don't know if the loop limits of the temp can be controled from config, maybe you should break into the code, looking for the routine that control the fans.
In theory the Android should take care of this, with the osciloscope app. extracting data from system, but in practice there can be a lot of implementation variants.
Maybe the user that showed the Android dektop on HDO1K knows more.
« Last Edit: January 04, 2023, 10:51:44 pm by skander36 »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16851
  • Country: 00
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #341 on: January 04, 2023, 11:09:05 pm »
Moving to Android might not be a bad idea.

No worse than moving to "Linux".

(yes, I know Android has Linux underneath)
 

Offline bob808

  • Frequent Contributor
  • **
  • Posts: 281
  • Country: 00
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #342 on: January 04, 2023, 11:37:40 pm »
Curious about the kernel config. Do they use a preemptible kernel? Would it matter in this case? And can it be done on Android?
 

Offline markone

  • Frequent Contributor
  • **
  • Posts: 730
  • Country: it
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #343 on: January 05, 2023, 12:54:44 am »
You can open a shell through ADB in Windows :

PS C:\ADB_Tool> .\adb.exe connect 192.168.xxx.xxx:55555
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.xxx.xxx:55555
PS C:\ADB_Tool> .\adb -s 192.168.xxx.xxx:55555 shell
rk3399_rigol:/ $ ls /sys/class/thermal
cooling_device0 cooling_device1 cooling_device2 cooling_device3 thermal_zone0 thermal_zone1
rk3399_rigol:/ $

It' possible to display CPU & GPU temps using the following command :

cat /sys/devices/virtual/thermal/thermal_zone?/temp

the scale is mCelsius, in my case they are between 40-45 °C.

I digged a bit in the filesystem looking for temperature set point, I was expecting a configuration file under /etc but this does not seem the case.

Most of temperature related files are under /sys/devices/virtual/thermal/thermal_zone0, here below folder listing :

available_policies
cdev0_weight
cdev1_weight
cdev2_weight
k_i
k_po
k_p
power
cdev0
cdev1
cdev2
slope
trip_point_0_temp
trip_point_1_temp
trip_point_2_temp
trip_point_0_type
trip_point_1_type
trip_point_2_type
trip_point_0_hyst
trip_point_1_hyst
trip_point_2_hyst
cdev0_trip_point
cdev2_trip_point
subsystem
type
mode
sustainable_power
uevent
integral_cutoff
offset
temp
cdev1_trip_point
k_d
policy

where, for example :

trip_point_0_temp = 70000
trip_point_1_temp = 85000
trip_point_2_temp = 115000

It's clear that there is a PID control loop for FAN control that makes use of a PWM peripheral to partialize FAN supply, now it would be nice to find where the target temperature is set, it should be something around 40-45 °C that is too much conservative, setting it higher should decrease FAN speed a lot.

if it weren't for the warranty seal I would have already replaced the original fans with a couple of Sunon 60x60x25, but I would like to try first the "soft" way.

CPU could easily be the coolest part on the board... There is still possibility there are chips on the board that are strong point heat source.. An IR photo with thermal camera would be nice to get best insight. If everything on board would be at +20°C over ambient, you would not need fan at all

Just checked the self check screen mentioned by skander36, everything is within 36 and 42 degree including frontend,  ADC, CPU, so it seems everything is well balanced as was expected from what we saw in the teardown video (huge diecast heatsinks).

Parameters found in the filesystem correspond to terminology used by ARM in one of its document that I put in attachment less two that are missing : "desired_temperature" and "switch_on temperature".

Anyway, temperature values that I can see in the document seem to confirm my theory : FAN regulation is way over conservative, the system is pushing them high when internal temps are well below 50 degrees, actually the exhaust air is lukewarm at worst.
 

Offline markone

  • Frequent Contributor
  • **
  • Posts: 730
  • Country: it
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #344 on: January 05, 2023, 01:01:50 am »
Moving to Android might not be a bad idea.

No worse than moving to "Linux".

(yes, I know Android has Linux underneath)

IMHO the move is toward a chinese device, Android is a consequence not a choice.
 

Offline markone

  • Frequent Contributor
  • **
  • Posts: 730
  • Country: it
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #345 on: January 05, 2023, 02:17:14 am »

It' possible to display CPU & GPU temps using the following command :

cat /sys/devices/virtual/thermal/thermal_zone?/temp

the scale is mCelsius, in my case they are between 40-45 °C.


You can see the temperature (CPU, ADC, FE) in realtime on board test section of UI, along with some voltages.
I don't know if the loop limits of the temp can be controled from config, maybe you should break into the code, looking for the routine that control the fans.
In theory the Android should take care of this, with the osciloscope app. extracting data from system, but in practice there can be a lot of implementation variants.
Maybe the user that showed the Android dektop on HDO1K knows more.

Try this command on device shell : "cat /sys/devices/platform/pwm_fan/hwmon/hwmon5/pwm1", it will return the FAN PWM duty cycle.

In my case 255 (and for everyone I guess), we have FAN @ 100% with internal max temp = 42 °C   :palm:

Passive trip points are @ 70 and 85 °C so it's clear that FAN management configuration is broken.
 

Offline bob808

  • Frequent Contributor
  • **
  • Posts: 281
  • Country: 00
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #346 on: January 05, 2023, 02:31:02 am »
Code: [Select]
echo "127" > /sys/devices/platform/pwm_fan/hwmon/hwmon5/pwm1does it lower the speed?
 

Offline markone

  • Frequent Contributor
  • **
  • Posts: 730
  • Country: it
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #347 on: January 05, 2023, 02:41:29 am »
Code: [Select]
echo "127" > /sys/devices/platform/pwm_fan/hwmon/hwmon5/pwm1does it lower the speed?

Of course i tried but ... permission denied.
 

Offline bob808

  • Frequent Contributor
  • **
  • Posts: 281
  • Country: 00
 

Offline bob808

  • Frequent Contributor
  • **
  • Posts: 281
  • Country: 00
Re: Hacking the HDO1k/HDO4k Rigol 12 bit scope
« Reply #349 on: January 05, 2023, 03:39:33 am »
also check if there's any "automatic" filename
Code: [Select]
# Set fan to manual mode
$ echo 0 | sudo tee /sys/devices/platform/pwm-fan/hwmon/hwmon0/automatic
 
# Set speed to 100%
$ echo 255 | sudo tee /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1

From here: https://wiki.odroid.com/odroid-xu4/application_note/manually_control_the_fan#fully_manual_way_to_control_the_fan_speed
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf