Yes we CAN

(NOTE: this is just radex's rambling, don't read this)

HS-wide CAN bus

use cases:

• sensors: door open/close, generic power on/off, thermometer, power meter?
• actuators: generic power on/off, close entrance door, HVAC (heater, vacuum suction), lights
• IoT: connect HSWAW state to IoT via CAN, trigger events remotely
• automation: trigger events at a set time or trigger multiple events from a single trigger, e.g. close door, power, lights
• fun

hsCAN family

ideas:

• canister - breadboardable CAN transceiver
• canary - CAN development board
• cancún - easy to use & low-cost CAN sensor/trigger module
• cantastic - CAN home base, power injection, IoT connection, base services like RTC
• canada - CAN repeater with power injection
• can??? - a powerful alternative for cancún with integrated RP2040 microcontroller board
• candela - CAN power sense and switch device (perhaps better to couple a cheap COTS module with cancún?)

vatiCAN

physical layer

• proposal: Cat 5/Ethernet, ideally in an unusual color that stands out from actual Ethernet cables (pink?)
• alternative: some other cheap twisted pair

for Ethernet: VCC, GND, CANH, CANL + 4 reserved wires

VCC: Power for CAN sensors and actuators. Too many cables otherwise, also, no power supply in otherwise powered-off rooms.

These accessories have to be low-power. We can't supply much current over CAN bus.

Which voltage? 5V would be easy to use, but again - not much power. 12/24/48V would be better, but cancún would need a proper power section. Alternatively, can use 3 wires each for power and ground at 5V for lower resistance

Physical bus connections - could use Ethernet crimping, but that's quite annoying. Is it possible to slice open CAT isolation safely and connect via IDC? That would be super convenient.

Bus would run underneath the ceiling likely. Bus stubs are probably undesired for electrical reasons… But running long wires from cancún down is not ideal. Maybe we can simplify by running bus at lower height?

Length - 30m (1Mbit max) is not enough. Can we create simple, cheap repeaters to have multiple buffered daisy chained sections? That could also simplify power supply problem.

Signaling

1Mbit most likely. Less is bad. CAN FD for more would be nice, but would likely require more expensive transceivers and it's not really needed

Addresses

8 bit to identify device (256 devices max) + 3 bit for device's "channel" (8 addresses per device)

since addresses also specify priority, a naming scheme would be needed

Message format

todo.

I don't think I want to use CANopen - it would probably be best, but it seems really complex. But we need something on top of 8-byte messages.

All devices should be able to respond to an "identify" request, which should be followed by a response identifying the device. For discoverability of available devices, fault detection by the master (device not heard from in x time), and to detect duplicate devices.

cancun would have a simple message format to transmit state changes, and to receive status requests and trigger requests.

Parts to use

Transceiver

JLCPCB Basic parts (great for prototyping):

• TJA1050T - $0.80 - 1 Mbps
• SN65HVD230DR - $0.52 - 1 Mbps

Other:

• CA-IF1042LVS-Q1 - $0.17 - el cheapo, up to 5 Mbps
• XL1040/XL1050 - $0.31, TJA1050-ish clone? 1Mbps
• TPT1042V-SO1R-S - $0.39, english datasheet, 5Mbps

Controller

• for canary/cantastic: RP2040, CAN rx/tx generation via PIO, ~$1.5-2.5 with peripherals
• for cancun:
  • would like to use PY32F002 ~$0.15, but not sure if it can bitbang can fast enough (24MHz)
  • if just barely not in spec, maybe a $0.28 F003 (32MHz) would do?
  • PY32 is desired because it's cheap, I want to use it for another project, and it has crystal and regulator built in
  • $0.46 gives you CW32F003F4P7 at 48MHz, $0.66 - CW32F030F8V7 at 64MHz [CW is low in stock, maybe not a safe choice?]
  • CH32V series has CAN built in, but the ~$0.20-ish ones are out of stock, and otherwise it's $0.59 at least - CH32V203
  • dedicated CAN controller ICs (with SPI output) like MCP2515 are over a dollar, not worth it. XL2515 (clone) is $0.98

cancun

Looks like CA-IF1042LVS-Q1 + CH32V203G6U6 is the best bet so far, pending verification. CH32V is not a popular architecture.

Plan B is to go with RP2040, as XL2515 + MCU does not save enough money to be worth it, and I doubt PY32 can do it

Plan C (lame) is to buy these super cheapo modules: https://pl.aliexpress.com/item/1005005995120126.html (6PLN a pop) and design a PY32F002 hat to go on top of it.

Cancun design

The most important part of this project is a CAN-enabled board that's:

• low cost, enabling cheap mass adoption by HSWAW
• very simple to use, in the simplest case just plug and play (predefined pin assignments, set address using solder jumpers)
• configuration-based for more complex cases - upload config by UART to set input/output configuration
• extensible for most complex cases - reprogram with custom firmware, add shields on top for extra electronics

Capabilities required for broad applicability:

• digital state inputs (on/off)
• digital trigger inputs (debounce and other settings, throttle, etc)
• digital state ouputs (on/off)
• digital trigger outputs
• analog inputs for sensors
• SPI, I2C bus for more complex sensors
• Robust, foolproof design - needs ESD, shortcircuit, reverse polarity protection

Mechanical design:

• Backside 2x4 2mm pitch IDC connector to splice into CAT-5 cable
• M3 or M2.5 mounting holes in the corners
• Two part 3D printed case:
  • FDM printed backside, with heat-set inserts for PCB mounting, and additional mounting features for the full case
  • clear resin printed front to proudly display PCB design + LEDs
• 2.54mm pitch pinout along top and bottom side
  • In simple cases, top side is not needed, and bottom side gets a 2.54mm screw terminal
  • for extensibility, female pin headers are soldered to mount top shield
• Standard footprint top shield possible (with space for it in the case design), without obscuring LEDs
• Status LEDs: Green for all good, Red for error (combination of blinking to indicate different issues), Blue to signal transmission / user configurable

Open questions:

• 5V logic level compat? - has some 5V tolerant pins, what about outputs? can we throw in one or two 5V-level outputs?
• Which part? Might want to use CH32V203C8T6 instead of CH32V203G6U6 - a lot more pins for only a few cents more
• is extra electronics needed to drive relay modules?
• how to interact with out DIN light switches? thermometers? noise level, switching power? detecting power consumption?
• overvoltage protection?
• is 2.54 screw terminal a good idea? maybe let's separate screw terminals from board to board connections? 5mm screw terminals seem to be a lot cheaper

Parts / BOM:

• 2x4mm 2mm pitch IDC connector - tbd
• transceiver: XL2515 - 0.31
• mcu: CH32V203G6U6 (28pin) - 0.59, or CH32V203C8T6 (48 pin) - 0.73
• power supply:
  • (12/24 to 5/3.3V): TBD, possibly TPS54331-based design (0.4-0.8)
  • 5 to 3.3V LDO: perhaps XC6206P332MR-G (0.09), maybe the 3-cent LDO?
• screw terminals - TBD - but could be 0.60 for 10 pins
• case - TBD
• LEDs - TBD - ~0.05
• protections:
  • reverse polarity - pmos - HL2301A (0.024) or cheaper
  • short circuit - resettable fuse? - 0.02-0.04
  • ESD - TVS diodes, H5VL10B - 0.01 (only on bus connections, maybe programming interface)