Hot air station Quick861DW custom firmware

[VeryFastSnail]

Hey guys 

So recently I had my quick 861DW hot air station stop working on me, So What I ordered brand spanking new mother board from china. But I still have old motherboard that is perfect right now, but has no firmware in it. so just a paper weight right?

I think not. I connected my AVR programmer to it, erased chip and now I do have ability to program it. I'm able to get code into it and it works perfectly on that chip (ATMEGA16A).

So right now I'm planning to create custom firmware for it. I'm using atmel studio 7 for programming it.

My progress can be found on github (https://github.com/VeryFastSnail/Quick861dw), I do have parcial schematics of moather board, but it's still in progress, so I will upload it as soon as possible.

Right now I do not have enough time for this project, because I'm on duty in military, but soon I will have more time.

Main problem is that lcd screen is controlled by SPI and I do not know how to control it. I suspect that it uses ht1621 driver. but I had no time to check that. (pictures of LCD is in my github repo.)


So I would like to ask people who owns quick 861dw, what features could be useful to you and for other people that programs AVR chips for help on coding it.

If you can help, please let me know it would  be very appreciated 

[VeryFastSnail]

EDIT:

It is using HT1621 lcd segmented driver, managed to get something on screen after connecting it to arduino. Now I have to implement it in avr.

[bill_c]

I was looking for something like this not long ago. I plan on using a few 861's for a process and want to control setpoint/flow/on/off and check unit status. (using serial)
I was just going to connect to the button inputs, but I wouldn't be able to check the actual process temp, or even verify that the simulated button presses actually registered.
Bookmarking this for when I get to work on this project.
That beep is annoying, but it would be fun if it played portal "Still alive" after a few minutes of use.

[VeryFastSnail]

Well, I do have good and bad news.

Good news are that I have managed to fully implement lcd, buzzer, buttons. There are more features planned, serial comunication virtual lcd display and more preset channels are included in those features. Soon I will get some vacation and during that time I’m plannin to implement more features. (PWM control for triac, adc for temperature control and so on)

Bad news is that I’m still on active duty in military and my progress is slow.


P.S. I’m planning to create windows form application that would let to configure quick861dw via serial, and get all the needed features. For example disable buzzer on startup, or simply make it less abnoxious, get virtual lcd on screen for OBS, unlimited presets with ability for integration of physical buttons.

Well tell me what you think, and what would you like to see implemented.

[bill_c]

Use limits on min and max settings to it doesn't melt when you send -30 flow and 9999 temperature.
Option of use last settings, use a preset, or use a default value at power up.
Option to NOT turn on heat if unit is switched on and the wand is not in stand. (operates normally after placed in stand)
Option to ignore the reed switch (reed in wand/ magnet in stand) and turn on/off with serial command.
Option of simple serial or RS485 with address (so I can control more than one with a single serial port).
I think it would be a good idea to use CRC with the serial.
It would be much better to use a cross platform user interface, maybe Python and Tkinter for example.
At least document the serial commands so others can do as they please.

[VeryFastSnail]

Use limits on min and max settings to it doesn't melt when you send -30 flow and 9999 temperature.
Option of use last settings, use a preset, or use a default value at power up.
Option to NOT turn on heat if unit is switched on and the wand is not in stand. (operates normally after placed in stand)
Option to ignore the reed switch (reed in wand/ magnet in stand) and turn on/off with serial command.
Option of simple serial or RS485 with address (so I can control more than one with a single serial port).
I think it would be a good idea to use CRC with the serial.
It would be much better to use a cross platform user interface, maybe Python and Tkinter for example.
At least document the serial commands so others can do as they please.

1)Temperature setting is going to be limited to defined MAX_TEMP and MIN_TEMP variables, so there will be no problem.

2) On powering up it will start with last set temperature witch is stored at eeprom at every placement of wand in stand(to save eeprom write cycles)

3) Reed switch ingorance going to be impelemented as you asked for.

4) I will try to implement serial with multiple slaves.

5) I do know some python, but issue is that developing with visual studio is much easier for me. If there are someone, who could help me with GUI on python, please drop me pm

[VeryFastSnail]

Update:

Since quick 861dw does not have native usb support by what I mean general ch330 serial to usb conversion. I would like to create some kits that would include:

Panel mount usb type b connector
Stencil for cutting port
Pcb that is responsible for usb <-> serial conversion
Instalation guide.

P.S quick 861dw version 2 pcb has unpopulated space for some kind of serial module, look for attachement (best guess is that it was intended for wifi module) it has few connections, and two of them are tx and rx, board outline is drawes on silk screen and manufacturin part like that is easy peazy.

My goal is to make it look OEM

This kit would be resonably priced, but schematics and parts list of it still would be free on github if you would like to make it yourself.

What do you think?

[VeryFastSnail]

Update:

My vacation is somehow postphoned to unknowed time...

I looked up tkinter, and it’s simpler then I remember. . Will use that for GUI.

Will give some info as soon as possible

[BlackFX]

This looks right up my alley, if I had an 861DW I would help out.

[Nominal Animal]

I don't have a Quick861DW either, and only use Linux (no Windows on any of my machines), but would gladly help if I could.
I've investigated using Python as an UI to a external microcontroller connected via USB/serial, quite deeply but limited to Linux.

In particular, I would recommend using a query-response protocol using plain ol' ASCII text, and a separate Python thread managing the communication (in blocking fashion), communicating with the UI using a Queue; all in Python 3.  This has shown me to be the absolutely most robust, while extremely straightforward, to implement.  I would recommend a very simple protocol, something like
    command-letter [ integer-value ] newline
for commands from host to 861DW, and
    command-letter [ integer-value ] newline
for successful responses, duplicating the received command (but note that you do want to regenerate it from the parsed values, instead of just resending the contents of the buffer you parsed the data from, so that the sender can detect transmission/logic/parsing errors!); and
    '!' command-letter [ integer-value ] ':' error-message newline
for error/failure responses.  This is easy to implement on both ends, and allows easy upgrade/extension path forwards for other devices.

Put the communication code in a separate module, and test it via a command-line interface, or by running it interactively in the Python shell.  If you need to develop the UI in parallel, put it in a separate program, not connected to the communication code, during initial development.  (Sometimes that kind of parallel development helps you decide what kind of interfaces the communication module should provide.)

Personally, I would put the serial port enumeration and access code in an OS-dependant module, because I really don't like the interfaces the existing ones provide, and on all non-Windows systems, it is better/easier to just use termios instead of any of the cross-platform serial implementations.  (You use the termios to put the tty -- the character device the kernel exposes for the serial port functionality -- in "raw" mode, and optionally a read/write timeout in deciseconds (units of 0.1 seconds).  It's very few lines of Python, and works like a charm.)

I didn't reply earlier, although I thought about it, because you are obviously on Windows, and I don't use Windows at all, and the serial port low-level management code tends to be the Achilles' heel, make or break the application.  My opinion of not using the existing libraries is contrary to just about everyone else I know, but it is only because they are not nearly as robust as a very simple low-level tty/termios based one is on Linux.  On Windows, it might be different; I dunno.

[Mosfet]

I propose SCPI as a communication protocol:
https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments
https://sigrok.org/wiki/IEEE-488

It defines temperature measurement and control commands, for example.

SmuView (Qt based GUI for sigrok) supports some SCPI devices, maybe temperature control can also be added:
https://sigrok.org/wiki/SmuView

[fenugrec]

Looks interesting. I just got my 861DW and was wondering if anyone had dumped the original ROM. Has anyone checked if the AVR has code protection enabled ?

The only thing that annoys me about the 861DW is the up/down buttons. I like rotary encoders. Would I go through the trouble of patching firmware and hacking the unit to add those ? meh, probably not. Not annoying enough.

Good luck; I don't have any suggestions except the obvious : do not add, or plan, any new feature until you get display, airflow and temperature regulation working reliably.

If you need, I can probably hook up a logic analyzer to probe the LCD interface, or scope other control signals if that would help.

[fenugrec]

Has anyone checked if the AVR has code protection enabled ?

Just verified this with a tl866 via the ICSP header : device ID is read as 1E 94 03 which is correct for an ATmega16A.
fuses are thus : (=0 means "programmed" aka "enabled")
BODEN=0
SUT0=0
CKSEL3=0
CKSEL1=0
CKSEL0=0

SPIEN=0
BOOTSZ1=0

BLB11=0
BLB01=0
LB2=0
LB1=0

reading flash and EEPROM areas gives garbage data (the lower 8bits of the address are returned).

That is from a spare display PCB (version 2.2, 20170803) which has the bug where channel presets are lost on power-down; new PCB (ver 2.3) was supplied under warranty; I didn't check the new board but I imagine it will be also locked.