Closed uploader18 closed 2 years ago
Hi, for technical stuff I prefer to communicate through github, that way others can learn and contribute.
Some things you should take into account when using sigrok and saelae logic analizer
Not sure if you still tried but in order to decode (serial protocol) , you should go for the decoder (waveform icon in pulseview) and select UART. And then try all the different combinations :)
Can you share the waveform? wetransfer, pastebin, etc, ...
BR
Hi, I agree with you that we should share it over github but till now i only know it is ModBusRTU protocol, 300 baudrate and that is it.I am attaching sigrok file and page from service manual on what data is sent to outdoor unit.For now i only have data from cooling mode.
On arduino forum are screenshots of service manual
https://forum.arduino.cc/t/toshiba-ac-indoor-outdoor-communication/910901
Looks like .sal format is not supported by sigrok (at least my installation, maybe recompiling with saleae format support could be possible, but haven't tried)
Can you provide a CSV file or other format?
Ok, I loaded it into Logic2 and what I see looks that there are problems with signal, small pulses that can be noise (see image) , or a poor voltage level (see https://en.wikipedia.org/wiki/Logic_level)
I also see that in RX this small pulses are 167 ns wide that would be 6Mhz approx 6000000 baudrate that it is not what is expected, I guess it will be more in the range of 2400 (typical values are 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200, 128000 and 256000 )
Try to set this filter https://support.saleae.com/user-guide/using-logic/software-glitch-filter and capture the signal again.
If you have and oscilloscope try to visualize the signal, the smallest pulse (given there are no glitches) will tell you the baudrate
I played this morning a little bit, for RX signal the shortest pulse shows that it could be a 100 bps signal (also a 150bps), then playing with standard 8N1 produces a result without framing errors that does not mean it is the right one but a candidate. But it is strange that "0" pulses are about 7.5 ms while "1" are 11.93 ms, I guessed the baudrate manually but here they give some hints and there is even an extension https://support.saleae.com/protocol-analyzers/analyzer-user-guides/using-async-serial
For TX there are a lot of errors, probably caused by the glitches that confuse the decoder. It is also worth to notice that there are 1.66 ms "0" pulses that do not seem to be just noise, but this pulse width would mean much higher baudrate while RX line seems to be around 100.
I attach you the .sal file with the decoding cooling_17c_vent3_serial.zip
I captured it again with 1us filterin logic2 and pulsewiev And RX is inverted
It looks better glitches are over, but this small pulses in the TX line confuse me (see image). Also RX line look like a CLK signal
How do you get pulsview output? Just using pulseview or converting it from .sal ?
I have been able to decode without errors using serial protocol with 120 baudrate 8N1 and RX non-inverted and TX inverted but I do not think thos e are the right parameters, they just fit.
Do you have experience with modbus? Do you think is it a modbus signal?
There is no RX or TX line it is single wire and ground it communicates over power cables. I am adding a picture from service manual so you can see how it is connected.
I used pulsewiev.
With serial protocol it is too easy or is it, if it is then we must check, i will make a signal capture with cooling and one with heating and we will see what if anything changes and to be sure I will capture first for cooling twice in a row and heating twice so that we see if anything changes. S1 is live wire, S2 is neutral and S3 is communication.
So, which cables are you analising, blk, whi, red from the indoor/outdoor unit. Do you have an oscilloscope to check the real signal?
No, i am measuring directly on MCU RX and TX line
s
hey, i was thinking what if it is a SPI serial communication since by pulse waves it looks like full duplex communication and is uses 50hz as clock from power source, that would explain why pulses are 20ms wide.......? check this out test with 50hz clock spi.zip ?
Hmm, but it there are olny 2 lines , then it would be i2c (SCL , SDA), does not it? But the thing is that SPI and i2c are used to interconnect elements in a board, not to send it outdoor/large distances. Maybe you are just reading an element from the board (sensor maybe) that communicates with the main board.
Anyway, we are learning a lot. :)
When looking at PCB, transmiter and reciver are connected via optocouplers together and then data is sent over one wire. Clock is taken from 50hz mains on both sides indoor and outdoor unit so there is no need for clock wire.there is no 12c or spi device on pcb and waveforms are taken from optocouplers that are wired to communication line labeled S3 in service manual.
I wanted to say that SPI requires 4 lines SCLK, MISO, MOSI and SS so i2c makes more sense. However this 50hz signal is strange, normally it is just noise from the mains but data fits this clock signal. Also from the decoding i2c has no sense to me because there are only addresses and not data. Typical i2c communication would be address+data, address+data, ...
I think that it is not pure spi but modified spi communication since MCU uses rx and tx lines and mains 50hz for clock.there is no need for SS pin since there is only master and one slave. For now i know that data sent from indoor unit(master) to outdoor(slave) is
Indoor umit capacity Cooling or heating Capacity demand Indoor heat exchanger temperature
I think we are close.
My code can access to heat exchanger temperatures but also it can be done through the wired controller, pg 18 from http://www.toshiba-aircon.co.uk/assets/uploads/product_assets/20131115_IM_1115460101_Standard_Duct_RAV-SM_6BTP-E_EN.pdf
And yes, we are closer!
capture RX TX CLOCK
could this be 3 wire serial communication
Yes, it seems a mix of SPI (TX) and serial (RX) but serial bytes have no sense to me. SPI bytes look better.
If seria-ish protocol I would expect one of the bytes to be datalength and present values in the range 0-10 and they are much bigger.
Do you have any progress?
No, for now i will try to invert RX line.I think it is some kind of custom com protocol.You...any luck?
No, it is completely different from the remote controller, :(
maybe this helps, MCU on the board is NEC 780076GK and communication is connected to TX2 and RX2.
I checked the doc and it seems to combine UART and SPI in some manner.
Also, I found this document https://www.cdlweb.info/wp-content/uploads/2018/07/Installation-Manual-TCB-IFLN642TLE.pdf It seems that protocol in outdoor units is called TCC-LINK. I thought this was the one I decoded for indoor units, but I was wrong and it is called sth like AB protocol
TCC-LINK is for remote control of VRV,VRF systems that uses modbus communication, same as your display and is open to public and uses U1,U2 or A,B terminal to communicate, on the other hand internal machine to machine protocol is different from any known protocol.
I inverted rx cooling rx inverted.zip
I was playing with the last data you sent but did not get any good result and you?
Any news on this? Should I close the issue and open it later if needed?
hey, good news, i figured it out but now i need help with checksum.
I get this data but no crc calculator works,
00 0F 00 34 00 21 10 5A 00 00 11 21 20 60 7F 53 00 1A 90 5A 00 00 11 20
Last byte is checksum i think?
Regards Žiga
Nice, I am glad you solved it, will you document your work?
I have playied with a checksum calculator but it does not give any reasonable values. Maybe your missing a byte? Also do not worry about checksum, just read the important info and ignore checksum.
ok so i managed crack that one too.
of you convert it to binary and count 0's in first 5 bytes you get checksum in last byte.
Regards Žiga
I cannot ignore checksum since i need it for two way communication.
Great, how did you guess it?
just a lucky guess and trail and error like everything about this protocol, about documenting it is a little complicated since i don't think toshiba will be very happy about it and I can get a lawsuit for making it public. All of their outdoor units run on the same protocol, from first inverter AC to newest 2023 heat pump.What do you think?
Well, as far you do not sell a product I do not see the problem. But if you do not want to make it public, would it be ok for you to share the code with me? I am curious about what information is running from/to the outdoor unit.
indoor to outdoor COMP. rev, TC sensor,TA sensor, heating/cooling, compressor on,error codes and indoor unit capacity
outdoor to indoor actual COMP. rev, TE sensor,TO sensor,TD sensor,TS sensor, (heating/cooling, COMP on set confirmation), compressor current, defrost signal,error code, FAN rpm,PMV opening position, capacity code.
If you are willing to help me write arduino library for communication i will share all the data with you.
I am just curious about the protocol. Last year I dedicated some hours to play with the data you provided and I would like to know how those signals were.
I can give you some hints about decoding it in arduino, moreover you have my code available to see how I solved it, this is the magic of open source :)
Hi guys, any progress on this ? I have several Toshiba RAS-M16GDV-E ducted ACs and based on the service manual they have the same serial protocol as you discussed in this thread.
What i want to achieve is to control the AC from an arduino (set mode & temp) but i don't want to use IR for that. Or maybe you know a modbus or other protocol gateway that could work with this kind of ACs ? (they don't have the AB or U[1-4] terminals).
Thanks !
I am working in decoding Toshiba indoor to outdoor communication protocol and need help.I have a wave form taken with sigrok and can't decode it.
If you are so kind write me an email so i have yours.
My mail: uploader18@gmail.com
Regards Ziga