j4cDAC: a new open-source DAC project

I thought a MAC address was 8 bytes.

It **MIGHT** be worth including an 'ID' byte in the broadcast and response packets which would be a simple user settable value (stored in NV storage) just as a more convenient way of identifying a DAC then needing the MAC address when setting up?

Ethernet disconnect should probably open the interlock.
After all the point of the projector interlock is to prove out cable integrity...

I might argue that a software crash is sufficiently serious to warrant a full on need to power cycle to reboot, not merely a WDT reset (Also makes debugging easier if the crash state is still around).

Two things that would make the far end of the link a bit simpler:-

Each command should have a 16 bit 'token' field that the remote end can set to any thing it likes and that is then echoed back in the response packet. This allows the remote end to match response to command if there are several things in transit at a time (Sort of like IMAP).

Could we have a command that sets the thing to automatically send a status packet every time the buffer fill drops below XXXX points? That way we can set the DAC to tell the PC when it needs more data, rather then having to ping it and guess. The level this is set to will determine the latency/reliability tradeoff.

It might be worth making one of the bits in the control word a 'loop here' flag which would allow the thing to run in either 'frame' or 'streaming' mode in terms of how it handles buffer underrun.

Probably more to come.

Regards, Dan.

What is the level of open sourceness with this project? Hardware? Firmware?

Interesting idea to use TCP to communicate with the DAC. I'm wondering if that could introduce unwanted latency in the command stream? Or is the idea that the buffer would always be full when the lasers are on using some sort of flow control? It might make sense to have the signal to each laser go to zero when the buffer is empty.

Mike

Quote:

---

Originally Posted by JohnYayas

What is the level of open sourceness with this project? Hardware? Firmware?

---

Firmware will be GPLv3. I haven't decided about the hardware design yet.

Quote:

---

Originally Posted by DMills

I thought a MAC address was 8 bytes.

---

Nope, 6.

Quote:

---

Ethernet disconnect should probably open the interlock.
After all the point of the projector interlock is to prove out cable integrity...

---

Only to the "next upstream device", I'd argue. Maybe make it configurable...

Quote:

---

I might argue that a software crash is sufficiently serious to warrant a full on need to power cycle to reboot, not merely a WDT reset (Also makes debugging easier if the crash state is still around).

---

Agreed.

Quote:

---

Each command should have a 16 bit 'token' field that the remote end can set to any thing it likes and that is then echoed back in the response packet. This allows the remote end to match response to command if there are several things in transit at a time (Sort of like IMAP).

---

Commands and responses will basically always be handled in-order, except for some "asynchronous" responses (like below), so matching them up should be easy - with the echoed command character as a sanity check. Is that good enough?

Quote:

---

Could we have a command that sets the thing to automatically send a status packet every time the buffer fill drops below XXXX points? That way we can set the DAC to tell the PC when it needs more data, rather then having to ping it and guess. The level this is set to will determine the latency/reliability tradeoff.

---

Sure, added.

Quote:

---

It might be worth making one of the bits in the control word a 'loop here' flag which would allow the thing to run in either 'frame' or 'streaming' mode in terms of how it handles buffer underrun.

---

Frame-orientedness seems like quite a bit of pain for questionable gain; i'd like to avoid it if possible...


New revision of the spec: http://moroso.emarhavil.com/~jacob/j4cDAC/protocol

Looks good. A few thoughts.

Do you have a thermal sensor on the board? If so, the board temperature could be part of broadcast packet. Could be useful.

Why not include a command to enable/disable the watch dog? Could be useful for debugging.

I am just curious as to how this will work from a synchronisation perspective as you will be buffering point data. Perhaps you can elaborate. I had envisioned a method of providing timing data with each point packet. Ie, issue "time to execute" and "current time" with each point packet. The DAC could then buffer as many packets as is possible, and play them out at the required time (min:sec.frames). - Rather then attempt to empty the point buffer at a set rate. Perhaps the DAC only need be synchronized infrequently. Your on-chip RTC has 1/100th second resolution I would assume.

Should the playback command include a parameter to select the playback source? (net/SD)?

Will you support transferring network frames to the SD? That would be cool. Load the SD via the network, play from SD.

Quote:

---

NAK - Invalid - ‘I’ (0x46) - The command contained an invalid command byte or parameters.

---

From what I see, you accept 16 bit values for point data, so unless you accept limit values for uint16_t control I don't see how you would detect invalid parameters.

Other than this, I also question the use of TCP. In the very least I would use TCP for control and UDP for point data frames. I am not sure what you expect the PC Software to do should it receive TCP NAK's to point data... If the NAK is due to a full buffer condition then the only course of action is to wait. This now get's very tricky to handle. How long do we wait before discarding the point data?

I would have preferred a system were the PC streams UDP data packets and the buffer level is reported, throttling the stream as required. Or a time synchronized method as I mentioned above (the PC should be able to know the buffer level at all times), although that does require the PC software to issue messages before they are to be displayed.

Feel free to shoot me down! :o

Quote:

---

Originally Posted by dnar

Do you have a thermal sensor on the board? If so, the board temperature could be part of broadcast packet. Could be useful.

---

Not onboard, no; if it's used for TEC control, then there will be multiple offboard sensors, and an onboard one wouldn't add much.

Quote:

---

Why not include a command to enable/disable the watch dog? Could be useful for debugging.

---

Best to use a custom build for that. The watchdog can be disabled by JTAG if necessary, also.

Quote:

---

I am just curious as to how this will work from a synchronisation perspective as you will be buffering point data.

---

The host, at any given time, knows exactly what the device is playing back (modulo network latency) based on the status packets. Anything other than a straight up stream brings up the issue of "what do we do if the host hasn't told us what to do right now?"

Quote:

---

Your on-chip RTC has 1/100th second resolution I would assume.

---

There is no RTC. The chip does have timers that can be used for a tick clock, set to any division of the 50.000 MHz +/-30ppm reference.

Quote:

---

Should the playback command include a parameter to select the playback source? (net/SD)?

---

I'm only worrying about network streaming for now; other sources will come later.

Quote:

---

Will you support transferring network frames to the SD? That would be cool. Load the SD via the network, play from SD.

---

Patience! :P

Quote:

---

From what I see, you accept 16 bit values for point data, so unless you accept limit values for uint16_t control I don't see how you would detect invalid parameters.

---

Yeah, that should be changed to just "invalid command".

Quote:

---

Other than this, I also question the use of TCP. In the very least I would use TCP for control and UDP for point data frames. I am not sure what you expect the PC Software to do should it receive TCP NAK's to point data... If the NAK is due to a full buffer condition then the only course of action is to wait. This now get's very tricky to handle. How long do we wait before discarding the point data?

I would have preferred a system were the PC streams UDP data packets and the buffer level is reported, throttling the stream as required. Or a time synchronized method as I mentioned above (the PC should be able to know the buffer level at all times), although that does require the PC software to issue messages before they are to be displayed.

---

There's really no advantage to UDP over TCP for this application. TCP gives an ordered, reliable stream, and if we wanted to use UDP for this application we'd have to build that on top of UDP *anyway*. If packets are dropped on the network, or come in out of order, it is simply not safe for the laser to just hold still for a while or play points out of order. The PC can throttle the stream as needed with this setup, since each packet is ACKed with the buffer status. We also don't have to worry about splitting transmissions into MTU-sized units with TCP.

The usual reasons for UDP are situations where broadcast/multicast is needed (not here), or where the overhead of keeping connection state is too much (not here), or where the time that would be taken for a retransmission is excessive (not here, on a local switched LAN). TCP seems to make much more sense.

As an application developer, I am not too concerned about all of the low level stuff being discussed here, but one request I have is too allow the output point rate to be changed at any point during the stream. For example, during the stream I will want to scan some frames at 15K while other scan at 30K with no interuption in the stream. I can handle it in the application by interpolating but it does not work well in all cases. So, if the DAC firmware can just change its output timing on the fly that would be great.

some pan/tilt/rotate/trapezoid/zoom controls would be nice to get on the DAC in order to project on any surface

Quote:

---

Originally Posted by shrad

some pan/tilt/rotate/trapezoid/zoom controls would be nice to get on the DAC in order to project on any surface

---

Since most DACs don't support this, it has become standard practice to do that in the laser show application. And since PCs are faster than embedded devices it isn't a bad thing to offload that functionality to the control software.

Instead of adding such features as image correction, path optimization, etc, to firmware, I think it would be a much more beneficial project to create some open source libraries for the PC side that developers could use to create laser applications. There was a time when I thought it would be nice to have all of this functionality in the device, but, with some experience I see the benefit in having it on the PC side instead.

Quote:

---

Originally Posted by JohnYayas

As an application developer, I am not too concerned about all of the low level stuff being discussed here, but one request I have is too allow the output point rate to be changed at any point during the stream. For example, during the stream I will want to scan some frames at 15K while other scan at 30K with no interuption in the stream. I can handle it in the application by interpolating but it does not work well in all cases. So, if the DAC firmware can just change its output timing on the fly that would be great.

---

The current protocol can do that, but only asynchronously (not lining up with a specific point). Do you need the changes to happen synchronized to the points? How often?