If you look in the NASA codes document you provided, message number 0x4254 corresponds to FSV 2011.
…in which case I think that we almost have an answer on our hands - that’s pretty conclusive.
The main question remaining for me is what are all those 0x55s doing? Could they be saying to the controller “Out of my way, vital Write message coming through”? (Please don’t laugh - the only handshaking I normally get involved with is after putting out on the 18th green… 
)
The interesting part is that it’s the same protocol on that link that on the F3/F4. The only difference seems to be the address of the source (0x80FF00 = public static final byte PC_CONTROLLER = (byte) 0x80;)
I’ll try to change FSV using this source address to see if the Write command is more accepted.
Basically, yes. I don’t think there is a master, or controller. If one device wants to send and it can’t hear anything on the bus, it sends the preamble of 0x55s. If it receives the preamble it sent, everything is fine, it then sends the packet. If the received preamble is corrupted, back off. So I think all devices send the 0x55s, they just get misread in the packet log as 0xFDs, or 0xFCs.
There are some subtleties in the use of preambles. In the case of the old hard disk protocol at the very end of the preamble is a timing violation on a byte boundary so that the receive circuitry knows where the data starts. But you don’t need that for a UART protocol, so I am just guessing up to now.
1 Like
It occurred to me that ChatGPT might be a better Google searcher than me, so I asked it how the NASA bus arbitration worked …
The Samsung NASA protocol, utilized in Samsung’s Variable Refrigerant Flow (VRF) systems, employs a communication model that does not require traditional bus arbitration mechanisms. Instead, it operates on a broadcast-based approach where all connected devices receive every message, and only the device with the matching address responds. This design simplifies communication but necessitates careful timing to prevent message collisions.
Communication Model
- Broadcasting: Messages are sent to all devices on the bus.
- Address Matching: Each device checks if the message is intended for it based on the address.
- No Arbitration: There is no central controller or master; all devices have equal potential to send messages.
Timing and Collision Avoidance
Given the lack of formal arbitration, devices must manage their own timing to avoid message collisions:
- Timing Control: Devices implement timing mechanisms to space out their message transmissions.
- Packet Numbering: Each message includes a unique packet number, allowing devices to detect and handle lost or duplicate messages.
- Retry Logic: If a response is not received within a certain timeframe, devices may retransmit their messages.(infogalactic.com, github.com)
Practical Considerations
This approach is particularly suitable for systems where:
- Low to Moderate Traffic: The bus is not heavily utilized, reducing the likelihood of collisions.
- Simple Topology: The network has a straightforward structure, minimizing complexity.
- Robust Error Handling: Devices are capable of detecting and recovering from message losses or duplicates.
However, in more complex or high-traffic environments, this model may face challenges such as message collisions or delays. In such cases, implementing additional timing controls or considering alternative communication protocols might be necessary.
If you need further assistance with integrating or troubleshooting Samsung NASA-based systems, feel free to ask!
I also asked it about the sequence of 0x55s …
In the Samsung NASA protocol, prior to each message, there is an optional preamble consisting of a sequence of 0x55 bytes. This preamble can be up to 100 bytes long, though the exact length may vary. The purpose of this preamble is not definitively documented, but it is believed to serve as a synchronization or padding mechanism to ensure proper alignment and timing of the communication. (github.com)
Following the preamble, the NASA packet itself begins with a header that includes information such as the source and destination addresses, message type, and payload length. The structure and content of the NASA packet are defined by the protocol specifications.
It’s important to note that the presence and length of the 0x55 preamble may vary depending on the specific implementation and configuration of the Samsung HVAC system. Therefore, when analyzing or interfacing with NASA protocol communications, it’s advisable to account for the potential presence of this preamble and handle it accordingly.
No particularly authorative sources, unfortunately.
1 Like
Good work, @toadhall, looks like you were right all along 
.
I’ve noticed that there are several very learned groups out there operating fora like OEM, so I would assume that that’s where ChatGBT is getting its data from.
Probably we could have save ourselves a few hours’ work yesterday by going to AI in the first place… 
There was one thing that troubled me, why the preamble of 0x55s was being received by SNET as 0x00, 0x01, 0xFC, etc. and then it received the packet start character 0x32 and all the following stuff perfectly. But I have a hypothesis. the 0x55 burst is not just to do with bus collision detection, but because of battery operated devices on the bus, say temperature sensors.
A battery operated device tries to minimise power consumption to extend the time between battery changes. It does this by shutting everything down, including oscillators when it doesn’t need them. So a battery operated temperature sensor will wake up every now and then, make a measurement, transmit the result and go back to sleep. The problem it has on the NASA bus is how does it receive unsolicited transmissions on the bus if it is asleep. This is where the preamble comes in.
The sensor powers down everything except the RS485 transceiver, the RxD line of which is connected to a processor interrupt line. When something starts transmitting the processor is woken up be the interrupt, starts up it’s oscillator and when it is stable starts executing code. Code will be executed to initialise the UART and it can start receiving characters. However, oscillator start up may take several ms, so the UART may mis-identify a data bit in the data stream as a start bit and all subsequent bytes read will not be 0x55.
To get the UART to start receiving correctly, the 0x55 preamble must be paused for at least 1 character time, and then the packet proper started. The receiving UARTS will then synchronise correctly on the start bit of the 0x32 at the start of the packet.
Voila, the preamble received will be corrupted (but it doesn’t matter) but the packet will be received correctly. I think the only way to verify this is with a storage 'scope or logic analyser on the raw RxD line, but I have neither. If any interested party out there has, and something with a NASA bus, and a spare hour or so it would be interesting to know …
Couple of comments/questions from a humble ChemEng (for whom a bus is what I get on to go to Swindon):
- Is SNET (a bit of decoding software ASAIAC) “receiving” this command? I’d have thought SNET was transmitting this message/command (the FSV reset), and it was the VCOM software that intercepted it as it passed to the MIM controller.
- What do you mean by “received by SNET as 0x00, 0x01, 0xFC etc”? I can’t see these in the message. Those hexs seem to be associated with outgoing (MIM-to-device) commands, rather than incoming (SNET-to-MIM) commands.
- Repeated 0x55s are obviously significant as they’re 101010101010… (The fact that there were exactly 100 of them in this particular message/command is I assume a red herring, as 100 is significant to humans but not to computers, so probably an arbitrary count assigned by the software writers to be long enough to be still going at the next interrupt request).
- I’m not sure where “battery operated devices” comes into it - there aren’t any on my set-up, and I’m not convinced that Samsung would have anticipated their presence when they wrote the MIM firmware.
Your patience in explaining all this to me (and I suspect many non-electronics folk on the forum) would be appreciated…
Yes, SNET is transmitting the message. I assume it also receives the transmission as it sends it in order to detect collisions.
I was looking at the original screen shot that you published. If you look at that you can see SNET receiving frames from the outdoor and indoor unit. Each is preceded by what looks like random stuff before the packet start marker of 0x32, so I am guessing those are incorrectly received 0x55s.
I would guess the burst is long enough to allow for the slowest device power up that Samsung have allowed for (if my theory is correct).
The EHS system that we are talking about doesn’t have any battery operated devices (as far as I know). But the NASA protocol is used in many other systems, especially air conditioning systems. So I could imagine they would design a protocol that catered for all the types of devices they could foresee using NASA.
Thanks @toadhall,
Of course I defer to your comms wisdom, but…
… the only time I’ve seen repeated 0x55s on the VCOM Monitor is when I’ve changed FSVs using SNET. I’m inclined to suspect that the aborted messages I see on VCOM are down to timing conflicts in incoming sensor data (e.g. the main EEV position report arrives at the same time as the compressor speed report, so the MIM just closes its ears until the next parse).
(That’s where a little knowledge gets you… )
Yep, that’s because SNET is transmitting, so when it receives it knows the timing and can receive the data correctly (assuming nobody else trashes it). When it is receiving any other frames it is in the same position as any other device on the bus and has to go through the process of getting to establish where the start bit of the 0x32 start of packet is.
Samsung do a NASA course
https://www.samsunghvac.com/trainingdocs/dvm-s-nasa-controls-introduction
and the slides for the course are accessible from that link. Unfortunately, by the look of it, I don’t think it would answer detailed questions about the protocol.
I may get a USB<->RS485 convertor, connect to F1/F2 and poke about in the protocol, but that will be a Winter project, too much other stuff to do in the summer.
If you do, I can recommend a couple…
Great news, I’m interested on buying one.
I’m eager to connect my AC to my HomeAssistant.
