During unboxing I thought maybe the black are on top of the laser module was a screen or something, but I guess not. I’m just curious what that’s about since the other two modules are all solid aluminum casing all around.
There also looks to be a blackish section on the top toward the back of the screen unit, like maybe it was removable, but I didn’t tug to hard.
These two modules communicate with one another using bluetooth. The black parts contain the antennas.
It is removable, but you have to apply some force the first time since it’s glued in place. Make sure not to damage the cable to the antenna if you try it. I would recommend leaving it attached though, there is nothing interesting on the other side.
Interesting. What are they talking about over BT they can’t do via the cable and why just the laser module?
It’s because of the camera. The camera is quite special since it needs to send a relatively large block of binary data to the screen (the captured picture) which is not needed by the controller in any way (The autofocus is handled by the screen). This allows it to use a separate channel like Bluetooth to communicate with the screen directly and not occupy the normal bus.
I’m not denying there’s a BT module, but there’s some indication that the camera data uses another channel. Here’s an extract from the documentation file Hardware-Link.md. There are dedicated pins for sending camera data over the cable. For all I know, they send camera data over both channels; we don’t have source code for the laser head or the screen yet.
Controller ↔ Laser module
- Wired link: laser power (remapped from step signal)
- CAN bus:
- indentify and configure module
- upgrade module
- read/write laser focus data
- Set FAN speed
- UART bus (remapped from enable and direction signals):
- upgrade camera module
- get bluetooth MAC address
- get/set bluetooth name
I could usefully be used by the controller. I’ve noted elsewhere that a CV (computer vision) routine running on the controller could be quite useful for setting calibration parameters.
Well, I can assure you that the Bluetooth connection is used for transferring the image, turning on the camera light etc. (Source: I read the decompiled/disassembled(?) source code of the screen module) The UART provides the same interface as the virtual UART over Bluetooth, but it is currently only used for setting the Bluetooth connection parameters. (Source: Controller source code).
Currently my controller has a bit over 30KByte of free RAM. In this segment, multiple FreeRTOS objects have to be placed and at least five stacks. That doesn’t leave much space to store an image, let alone process it. Especially since the camera seems to produce RGB images with probably more than 10kPixel. So I don’t know how you want to archive that, but maybe I’m missing something here.
Also I don’t see the motivation since the current approach of running CV on the Screen which has a much more powerful CPU and can run arbitrary GCode and other commands to adjust calibration data if necessary seems to make a lot more sense.