Common mistakes — J1939 gateway

General CanCan problems (LED codes, box invisible on the bus, firmware update) are in Common mistakes. This chapter is what goes wrong with the genset side specifically.

No genset ever appears on device/4/#

Likely cause	How to tell	Fix
The J1939 bus is not at 250 kbit/s	total silence rather than errors: nothing is decoded at all	the gateway forces 250 kbit/s on CAN 2 at every start and cannot be told otherwise. The genset must run at 250 kbit/s
CanCan v2: the second bus supply	a v1 in the same installation works, the v2 does not	known limitation of this firmware — see What you need
The genset is not one of the two recognised families	other J1939 traffic is visible on the bus but nothing is published	this firmware translates Fischer Panda and Cummins Onan gensets only
The genset never claims a J1939 address	it is powered but silent, or only answers when polled	the gateway asks unknown senders to introduce themselves and translates only devices that answered. Fix it on the genset side
CAN 2 not wired, or wired to CAN 1		CAN 1 is the MUXEN bus, CAN 2 the genset
The J1939 bus is not terminated	60 Ω across the powered-down segment; 120 Ω means one termination is missing	one 120 Ω at each physical end

The genset disappeared from the screens

A Fischer Panda that says nothing for two minutes is dropped: its MUXEN device is removed, its alarms go with it, and it comes back by itself when it starts talking again. Normal after a shutdown at the genset's own panel. If it happens while the genset is running, suspect the bus: wiring, termination, or a connector.

A Cummins Onan is never dropped once it has been seen. Its control powers itself down about five minutes after the genset stopped, and goes silent on J1939; the gateway then keeps its MUXEN device and reports it off (state 0) until it wakes up. Only a restart of the gateway forgets it.

The genset took an instance number I did not choose

That is by design: the MUXEN instance is the genset's own J1939 instance, read from its address claim the first time it is seen, and stored from then on. Two identical gensets therefore get two different numbers without anyone typing one.

It goes wrong when the number collides with another generator already on the boat — values that jump between two sources, commands reaching the wrong genset. Check with muxen-uds -i can0 scan, then renumber:

muxen-uds -i can0 -F 4 -I <current> writeconfig --name InstanceNum --value <new> --reboot

Restart the box after renumbering. Without it the genset starts publishing on the new number immediately, but muxen-uds still answers on the old one — which looks exactly like a box that has half accepted the change.

Start and stop from the screen do nothing

Likely cause	How to tell	Fix
It is a Cummins Onan	GensetModel reads 2	that profile is read-only. Start it at its own panel
The genset is not in the right state	a start is only acted on when the genset is off, a stop only when it is on	wait for starting / stopping to finish and repeat
A stop is being refused	noCutOff is true on the life topic — the bank is below SocToStart	send the stop with "ForceCmd":true, or wait for the charge
A start is being refused	noStart is true — the bank is full, so an automatic-stop run would be cut off at once	send the start with "ForceCmd":true

clearError in the command payload is accepted by the bus and does nothing on this firmware. Clear faults at the genset.

The genset never starts on its own

Automatic start exists for Fischer Panda only, and only once the genset is bound to a battery zone.

Likely cause	How to tell	Fix
BindToParc was left at its factory value	it reads 255 (stand-alone), not the zone number you expect	it is latched to stand-alone the first time the genset speaks. Write the zone number explicitly, with --reboot
BindToParc was changed without a restart	the value reads correctly but nothing changes	the zone is resolved once at discovery — restart the box
The bank never gets low enough	the soc on the battery zone stays above SocToStart (default 15 %)	raise SocToStart if that is what you want
The zone has no battery reporting into it	a stand-alone zone reports a fixed 50 % and no current	check that the batteries of that zone publish on the MUXEN bus

The genset stops by itself, or refuses to

A Fischer Panda run is ended by the gateway only when the gateway started it. A run started at the genset's own panel is left alone — with one exception: whatever started it, the gateway stops the genset at once if the battery zone reports a fault or asks to be switched off.

Otherwise a gateway-started run ends when the bank is full (100 % and the charge current down to ChargeCurrentToStop), when the zone stops asking for charge, or — for a run started to assist a heavy load — once the load has dropped back for long enough and the state of charge is above SocToStopAfterCurrentHelp. A command with "ForceCmd":true suspends all of that until the next stop.

The gateway also needs the Fischer Panda's own auto-start mode to be on, and re-enables it whenever it finds it off — turning it off at the genset's panel will not stick.

Current and power always read zero

Expected on a Cummins Onan: that profile publishes state, engine speed, AC voltage and temperature, and nothing else. Current and power stay at zero. A Fischer Panda publishes all four.

The temperature of a Cummins Onan looks wrong

Known limitation: the value is derived from the genset's fuel temperature and its offset is not right. Indicative only — read the genset's panel for a figure you can act on. A Fischer Panda reports its engine temperature correctly.

Alarms appear, then clear themselves

Known limitation. Alarms are published on device/4/<instance>/error/<code>, but a diagnostic code the gateway does not recognise makes it clear its whole alarm list — including alarms belonging to other devices. An alarm page that empties itself for no visible reason is this, not a fault that went away.

Only a Cummins Onan produces alarms; a Fischer Panda publishes state and values but no diagnostic codes.

muxen-uds locate does not blink the box

The routine that normally blinks the LED is reserved on this firmware and does nothing. Identify the box by its UID.

A setting I wrote had no effect

Most of what matters here is read once, at startup or at discovery: the box's own instance number, the genset's instance number as seen by muxen-uds, and the battery zone. Write with --reboot and you will never meet the problem.

After a factory reset the genset is back to a number I did not choose

Expected, and harmless: the genset is rediscovered and takes its J1939 instance again, exactly as on the first day. Every threshold, the battery zone and the instance you had chosen are gone. Restore them from the CSV saved at commissioning.