Page 2 of 7 FirstFirst 123456 ... LastLast
Results 11 to 20 of 61

Thread: j4cDAC: a new open-source DAC project

  1. #11
    Join Date
    Dec 2009
    Location
    Sydney, Australia
    Posts
    7

    Default

    Any basic estimation on the final price? Like, nearest hundred is enough.

  2. #12
    Join Date
    Jul 2010
    Location
    Netherlands
    Posts
    3,314

    Default

    My main feature request *I guess it's hard though*

    You told me on IRC that it's processor is quite good.

    How about you make an good use of that SD capability and make it that you can develop programs that execute from the SD card without having a computer connected.
    Maybe A little display that can be attached on the dac which give you a little degree of control.
    This can be practical is someone wants a very compact setup at times, it's off course by far no replacement of the pc, but it's a nice feature

  3. #13
    Join Date
    Dec 2007
    Posts
    7

    Default Support for the spaghetti

    Support for the spaghetti is a great idea I have also bought spaghetti program

  4. #14
    Join Date
    Dec 2009
    Location
    Seattle, Wa
    Posts
    413

    Default

    Way cool that you are making this open source. I think the most important thing at first is compatibility with existing tools like Spaghetti, EasyLaze, etc.

    Longer term I would be interesting in helping with programming on the ARM or PC side. I'm very interested to work with a DAC that has an good programmability model. I have a sound card DAC that is useful but not super reliable. I love my FB3 but there is zero programmability.

    What do you think the parts cost will be?

    Thanks,
    Mike

  5. #15
    Join Date
    Dec 2010
    Location
    DC/VA metro area, USA
    Posts
    554

    Default

    First, awesome idea and a nifty looking project!

    I'd consider adding UDP support for local host-based show streaming, unless you're sure you 1) want to and 2) have the horsepower to buffer and support TCP for what amounts to a real-time display. If you drop a packet, sometimes it may be better to skip it and move on than to spend a lot of time recovering it.

  6. #16
    Join Date
    Jun 2010
    Location
    Australia
    Posts
    3,734

    Default

    Quote Originally Posted by tribble View Post
    First, awesome idea and a nifty looking project!

    I'd consider adding UDP support for local host-based show streaming, unless you're sure you 1) want to and 2) have the horsepower to buffer and support TCP for what amounts to a real-time display. If you drop a packet, sometimes it may be better to skip it and move on than to spend a lot of time recovering it.
    I agree, this is fairly typical method of dealing with realtime streams. If you missed a packet then by the time you have it re-transmitted etc it's irrelevant if it arrives late.
    This space for rent.

  7. #17
    Join Date
    Sep 2006
    Location
    Netherlands
    Posts
    1,435

    Default

    Quote Originally Posted by dnar View Post
    I agree, this is fairly typical method of dealing with realtime streams. If you missed a packet then by the time you have it re-transmitted etc it's irrelevant if it arrives late.
    As long as the device acts predicable in the mean time.
    i.e no stationairy beams or such.
    Repeating the frame that's in the frame buffer seems to me the best option if the data stream becomes occluded.

    Does this device have brownout detection ?

  8. #18
    Join Date
    Aug 2009
    Location
    Bristol, England
    Posts
    333

    Default

    There is a hardware WDT in the micro and the power up reset on those things is pretty robust these days.

    Power input is via a switching regulator with a very wide input range, the analogue stuff will go south well before the cpu does and the interlock relay needs a pin to be toggled to hold it in, either steady state will not keep the relay pulled in.

    Thus even before the WDT fires the interlock will open as the micro fails to keep the interlock pin moving.

    On any future V2 it might be worth thinking about hooking a couple of comparators to keep an eye on the various DC rails so the interlock can respond to a low power rail condition.

    Much thought has been given to stationary beams, and actually the safest thing to do (if not the prettiest) is to close the shutter and zero the colour signals until the host processor gives an explicit restart command (still move the scanners, just dont radiate until told to).

    Of course most of the firmware still remains to be written, and I dare say there will be much experimentation with different approaches.

    Regards, Dan.

  9. #19
    Join Date
    Jun 2010
    Location
    Australia
    Posts
    3,734

    Default

    You need to ensure loss of comms results in safe operation, not just loss of rails or CPU watchdog timeout.

    I have worked as real-time embedded developer of almost 20 years, if I can help in anyway, please just PM me.
    This space for rent.

  10. #20
    Join Date
    Apr 2010
    Location
    USA
    Posts
    216

    Default

    Here's a first whack at things. Thoughts?

    https://docs.google.com/document/pub...byfluWNHM7Li5k

    Google Docs is doing strange things to the formatting there. I'm going to move over to a proper wiki or something tonight.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •