Youyue 858D+ some reverse engineering + custom firmware

[Gixy]

Well, found some time to work on this.
I took the V1.45 version of the software and made the modifications from Wayne (wguibas) on the relationship between adc_raw and temperature, as well as min and max values for fan speed.
His formula is temp = adc_arw/2.4 + offset (33 by default).
I flashed the software and made a complete set of measurement. I don't know why, but this time the results are much better than before: the bias between target and mesure from 80°C to 400°C stay inside +/- 1 or 2 degrees: excellent! I made a linear regression to determine the equation and found:
temp = adc_raw/2.456 + 35, which is pretty close to the software's formula above, so I changed nothing.
Many thanks to Robert and Wayne!
Denis

Kaleep 858D+ with MK1841D3 chip

[happydad]

Robert, I may need some help.  I was able to flash the v1.45 binary to the ATMega168A chip.  But when I turn it on and attempted to measure the fan speed pulses, I got nothing.  When I first turn it on, the fan turns on for about 2 seconds before shutting down, and the display then continuously read 'fan spd'.  Any idea what's going on?

[madworm]

Did you try the manual fan-test to see what the device gets from the ADC?


Fan Speed/Current:
==================

* Can be tested when pressing up while powering on, current value is shown and updated.
* Hard reset to leave

https://github.com/madworm/Youyue-858D-plus/blob/master/Docs/modes_of_operation.txt

[happydad]

Thanks for the quick response, Robert.  I tried the manual fan test and it appears to at least blow air  .  When I look at the scope, it doesn't seem as clean as yours, i.e. I get a double pulse no matter what speed I'm at.  See Attached and sorry for the poor quality.  I assume this is ok?

Also, The readout is always 23, even when I crank it up.  It only jumps to 940 or so when I max out the speed knob.  More hints?

[happydad]

Hi Robert,
I have messed with the pots during fan-speed testing.  For the most part, I was able to get a good pulse, except at the lowest speed setting, the pulse is erratic.  Anyway, I think the mod is working.  However, when I power it up in its default state, I still get the 'fan spd' message.  The manual mentions adjusting fsl/fsh/fcl/fch.  So I attempted to un-comment the bldc section of the youyue.h code.  After building it using AVR Dragon, it now appears that the leds are not displaying, i.e. dead.  The fan now runs and speeds up according to the knob.  So I'm now lost.  Since I'm really new to AVR programming/compiling, is youyue.h all I need?  Or do I need some other files like youyue.cppproj?  I am using Atmel Studio 7.
Thanks in advance.

[bitwelder]

I recently got a WEP 858D, which is a second brand for Yihua (the station has even a QR code to check the 'authenticity' (*), and in the 'certificate' they state that Yihua Electronics has two brands YIHUA and WEP).

It uses the Samsung chip S3F94CEEZZ-DK94, but the PCB seems a newer version than what wguibas showed in this picture (V5 vs V2).
Do you think the adapter board would work with it, or does it need to be further changed?



(*) the check seems to work so that if the web page linked to the unique 'security code' has been accessed more than once, it warns you of a possible fake (plus it reports the timestamp of the first access).

EDIT1: The version name seemed like a V5, but actually after clearing it, turned out it's a V8.
EDIT2: front and back photos of the PCB at https://imgur.com/a/YPXcD

[madworm]

Since I'm really new to AVR programming/compiling, is youyue.h all I need?  Or do I need some other files like youyue.cppproj?  I am using Atmel Studio 7.
Thanks in advance.

There need to be modifications in the .h and .ino files. I've added a few comments today about that.

I haven't used AVR Studio since version 4. I don't even know if 7 runs on my XP VM. I usually don't touch anything windows while at home.

Do you have a build-log from your experiments? Maybe Studio changed the fuse settings?

[happydad]

Hi Robert,
Some progress.  I was able to compile your 1.45 code with the bldc fan mod.  Now when I turn it on, it displays "1.45", then stop at "FAN Cur".  Can you explain the difference between fan_current_min/max and fan_speed_min/max?  The section of code in .ino says
#ifdef CURRENT_SENSE_MOD
CPARAM fan_current_min = { 0, 999, FAN_CURRENT_MIN_DEFAULT, FAN_CURRENT_MIN_DEFAULT, 22, 23 };
CPARAM fan_current_max = { 0, 999, FAN_CURRENT_MAX_DEFAULT, FAN_CURRENT_MAX_DEFAULT, 24, 25 };
#else
//
// See youyue858d.h if you want to use the 'FAN-speed mod' (HW changes required)
// The following 2 CPARAM lines need changes in that case
//
CPARAM fan_speed_min = { 120, 180, FAN_SPEED_MIN_DEFAULT, FAN_SPEED_MIN_DEFAULT, 18, 19 };
CPARAM fan_speed_max = { 300, 400, FAN_SPEED_MAX_DEFAULT, FAN_SPEED_MAX_DEFAULT, 20, 21 };
#endif

whereas the ones in the .h file are
CPARAM fan_speed_min = { 0, 999, FAN_SPEED_MIN_DEFAULT, FAN_SPEED_MIN_DEFAULT, 18, 19 };
CPARAM fan_speed_max = { 0, 999, FAN_SPEED_MAX_DEFAULT, FAN_SPEED_MAX_DEFAULT, 20, 21 };
//
#define FAN_CURRENT_MIN_DEFAULT 30UL
#define FAN_CURRENT_MAX_DEFAULT 71UL

So what does 'UL' mean?  Does fan_speed_min/max refer to just the resistor mod without the BLDC comparator stuff?  I have the LM2904 comparator mod done, so should I be looking at fan_current_min/max instead?  Also, I am confused about what was displayed in fan test mode.  When using your binaries at github, I thought I was getting numbers in the high 900 range.  But now with the binaries derived from youyue858d.h and youyue858d.ino, I get readings between 23-81, and the time constant is really slow.  Any help is greatly appreciated.
Thanks in advance.

[madworm]

* The "current sense mod" & related settings just measures current via the 1R resistor, quite useless for the BLDC fan. Doesn't detect stalling. I don't ever use this. Maybe it should be thrown out.

* The normal "fan speed" settings (code as is) are used for the unmodified device (no 1R resistor...), it measures BLDC supply voltage & somewhat correlates with fan speed, but still doesn't (can't) detect stalling.

* The "fan-speed hw-mod" requires adjustments to the "fan-speed" settings as described in the code. This is due to other numerical values coming from the ADC. Once the device has run for a minute or two, readings in fan-test mode should be ranging from > 500 to about 1000 or thereabouts. When the fan is stalled (piece of paper) it should read below 450.


"UL" stands for "unsigned long" It is to make sure the right data-type is used for constants. I know my usage of this is a bit "lax".

https://stackoverflow.com/questions/13134956/what-is-the-reason-for-explicitly-declaring-l-or-ul-for-long-values

Now to the hex files. I've compiled these so they work on my device, constants chosen to match the settings for the mod described in the manual for the mod (see github).

https://github.com/madworm/Youyue-858D-plus
https://github.com/madworm/Youyue-858D-plus-FAN-speed-mod
https://github.com/madworm/Youyue-858D-plus-MCU-adapter

[happydad]

Robert,
To recap, I have done the hardware mod.  Fan test mode showed values in the 500-999 range from min to max.  It some times underrun and overrun, but I guess that is ok.  When I used your binaries taken from the github area, I get '1.45' displayed, and then stops at 'fan spd'.  I then proceeded to modify the code by extending the range like so:
CPARAM fan_speed_min = { 0, 999, FAN_SPEED_MIN_DEFAULT, FAN_SPEED_MIN_DEFAULT, 18, 19 };
CPARAM fan_speed_max = { 0, 999, FAN_SPEED_MAX_DEFAULT, FAN_SPEED_MAX_DEFAULT, 20, 21 };

I am assuming the max range is 0 to 999.  Right now, I get the attached display at lowest to mid range.  At max range, I get the 'fan spd' display.

So are the above parameters correct?  What should I do next?

[madworm]

The range extension looks ok to me. You did change the min/max defines as well, didn't you?!?

I don't know what this "rrr" is supposed to be. Never seen that before.

Fan speed set to max on the dial will cause an error. This is intended.

As of now, the fan-speed must be greater than FAN_SPEED_MIN and smaller than FAN_SPEED_MAX to pass the test. You can change these variables in the config menu of the device.

When I have time & inspiration I will have to clean this up a bit. But right now life / job come first.

[happydad]

Latest update:
It seems that there's an issue with the display, because when I removed the wand from the cradle, it started to get hot.  When pushing the up and down buttons, it sure looks like the display wants to reflect the temperature, but it's just putting out gibberish.  Also looks like pushing both buttons together gets it to the config menu.  It's just that I can barely figure out the gibberish on the display.  Anyone have any idea?  The thing is that when I am in fan test mode, the display is behaving correctly.  In normal mode, it starts up displaying '1.45' correctly, and then gets into the 'rrr' with the wand on the cradle.  With the wand off the cradle, that's where I get garbage.  I suspect perhaps clock is going too fast?  But then why is it okay in fan test mode?   

[madworm]

Fuse bits are correct? There is one "clkdiv8" that would certainly mess things up.

[madworm]

Could you post a video somewhere?

[happydad]

Here you go:
https://www.youtube.com/watch?v=9cls7NOD0s8&feature=youtu.be

[happydad]

Hi,
I would appreciate if you guys can drop some hints as to why I'm having problems with the display:
https://youtu.be/VwirBtHQnIY

I am using Atmel Studio 7.0 to burn the '168 chip, and I suspect something's not translated correctly.  Why would the speed test display be fine, but the main program's display is all whacked?

[madworm]

The firmware version gets displayed for way too long. It should only show for 1 or 2 seconds. This makes me believe that either the clock settings are wrong (fuse bits, DIV8) or that the code was compiled with the wrong F_CPU define. Either way, the timing is way off.

Could you post a Screenshot with the fuse settings after you've read them from the chip? The programming dialogue should have that option.

[madworm]

I stand corrected - to some degree at least.

I've tried to replicate the error you get by deliberately programming the "CKDIV8". The result was unspectacular,  the device still worked, just awfully slow. The display was flickering noticeably.

I didn't see the strange "rrr" artefact at all.

To test against this possible issue I've added some dumb code that checks whether the timing is grossly off & causes a watchdog reset if that is the case.

It is quite a puzzler that the firmware version is displayed correctly, and only after that everything goes south with the display.

[happydad]

Fuse settings are attached.  I don't think this is an issue with different pinouts, because the LED segments work correctly in fan test mode.  I should say that I'm not too familiar with Arduino.  So when using AS7.0, I had to point it to the Arduino IDE directory that I had to download and install separately.  It was version 1.6.9 that I downloaded, if it means anything.

[madworm]

The fuses look OK.

I use 1.6.4 here, if it means anything ;-)

[Gixy]

@ happydad

I don't know how you're using ATmel Studio 7 (AS7) to compile the sources. If you use the VisualMicro plugin, you can manage things just as  a pure Arduino project. But if you want to create a true C++ project, this is another story:
Converting the arduino project (.ino) to a standard Atmel Studio C++ project is not a simple thing. I did it and found some problems.
The main one has been corrected by the Atmel support who sent me a modified arduino.dll (I'm using Windows 10). I also modified the functions and arguments types/cast for EEPROM access which are different in the Atmel Arduino lib.
see https://www.eevblog.com/forum/microcontrollers/atmel-studio-7-create-project-from-arduino-sketch/msg969568/#msg969568
Here are the two files sent by Atmel to correct the bug in the "create project from Arduino sketch" function of AS7, as well as the .cpp source with the modifications for eeprom access. This source is for the station with the MK1841D3 MCU, which implies to modify the conversion formula for temperature: just suppress the division by 2.4. Then you can insert the modifications for the fan you're trying to make...

[happydad]

Hi Gixy,
I go to File-New-Project, then pick "Create project from Arduino sketch".  As you can see from the screenshot, VisualMicro plugin was also there, but I didn't go that route because it seems to want to see an Arduino board, which I don't have.  It gave me these messages:
"Intellisense build error: Object reference not set to an instance of an object.
Visual Micro found a missing or redundant board selection
Please ensure a valid micro-controller application and board are selected".

How would you add the .ino and .h file going the VisualMicro route?  At this point, I'm only guessing there's an issue in the translation.  Perhaps there is really an issue with AS7.  I would like to try your files, but I think your zip file is empty.

[Gixy]

Hi Happydad,
Sorry for the zip file, I uploaded it again and it seems to be OK now.
There is 3 ways to proceed:
- Using the Arduino IDE. Indicate Arduino/Genuino Uno as the target and that's it. You load the .ino file and build the binary (.hex) without bootloader. This is for sure the simplest solution. You can then flash the firmware with your programmer (TL866 or anything else)
- Using AS7 with VisualMicro. File / New / Project / (VM) Arduino sketch and select Arduino/Genuino Uno as a target. No need to modify anything in the sources, VisualMicro does the job to link everything. You can then flash the firmware with the binary stored in the release directory.
- Using AS7 after converting the sketch into a normal C++ project. File / New / Project / Create Project from Arduino Sketch. This is the hardest way, where you need the patch files I posted and you have to modify the sources in order to compile the project without errors. Use this method only if you're conformtable enough with C++ development.
Clearly to get your project working rapidly and focus only on hardware tuning, go with the first solution.

[madworm]

Did you ever try the .hex files I've posted here?

These things are "known-good" & not working with these would point to a non-code issue. Maybe chosen wrong target MCU when uploading (i.e. 168 code in 328 chip or vice versa).

[Gixy]

Right, first thing to try...