#150 – Solar, FPGAs and Maxim Integrated – Solar Shopper Sickness



Dave is under the weather this week, but we did a show anyway. How’s THAT for dedication?

Thanks to the Boston Public Library for the somewhat creepy clown picture.


  1. says


    script to unmute microphone when button is pressed, you need to edit it so it mutes when pressed instead.

    get usb keyboard (or mouse with extra buttons), rip it apart, take pcb out, connect pins you want (for example Capslock, or mouse button 5) to a big red button, done.

    python to FPGA? interpreted single core language to FPGA? What could possibly go wrong? Sounds as brilliant as using 700MHz ARM to blink a led.

  2. says

    Within 10 years, an application engine will be built that allows performance hungry applications to compile down to hardware. With this, software correctness will re-emerge as it will be possible to determine the correctness of a program compiled down to hardware from the bottom-up. This would be implementation correctness, not algorithm correctness of course. Uses for such a thing? 3D user interfaces that will make today’s user experience look crude.

  3. says

    Broadband over powerline (or BPL) on a large-scale has a very bad connotation from most RF minded folks. There were (and still are) some large-scale trials of BPL and they’re like an RF nightmare. Just broadband RF noise everywhere. I’ve heard they’ve made significant filtering improvements, but at it’s core, a Power Transmission line != to an RF transmission line. Low-power smaller scale deployments like the one the Maxim chip is focused on make more sense to me.

    • says

      Isnt placement of power lines outside on poles the problem? There are countries that bury all power lines deep underground.

      • says

        @rasz_pl Yes, and in Minnesota where I live the whole state is pretty-much set up this way except for the BIG lines coming out of a plant to sub-stations. However, even if all the lines are buried, the interference is reported to be there. The Amateur Radio community is very much against BPL and the ARRL has been lobbying congress to prevent it because it is not a minor annoyance, it is a big deal if you are affected by it and BPL ends-up unlawfully interfering with a primary service as a result. Of course law enforcement and justice are not necessarily immune to financial influences.

        • says

          I know HAMs are up in arms about this, but all reports of interferences that I saw involved neighborhoods with overhead last mile infrastructure.

          It could still be useful technology everywhere with buried cables, but now we have this knee jerk reaction at the mere mention of BPL.

          • Troy says

            If you have have a clue about RF, you know that it is a much bigger deal for everyone that uses RF spectrum of any sort. Low power small scale deployments are OK, but it’s an inherently flawed technology.

    • says

      Yeah, we had a trial a number of years ago in the UK (before DSL was rolled out, 56K dial up was the norm), the problem faced by the energy company running the trial was that the street lighting columns (lamp post) behaved like rf radiators and the HAM community were up in arms (given they have such a rough time of keeping their noise under control).
      The unit that was fitted was little more than a filter and a PSK modem, and it was connected after the main supply fuse but before the credit meter. I ditched the trial, as 56K dialup was much faster.

  4. Chris says

    12 years ago I was selling power line network adapters at Dick Smith. They were 14mbit back then too. I’m sure you can get much faster ones these days.

    Old news Chris.

  5. Lee says

    Just to clarify something that you guys got a little mixed up in the show.

    MyHDL isn’t Python to hardware. It is an HDL just like Verilog or VHDL. The purpose is to fix some of the problems with existing HDLs to make them easier to use, and one of the main reasons it is based in Python is to allow you to use high-level language features to VERIFY your design, not actually run in hardware. See:

    Just like Verilog and VHDL, it has a limited subset of features that are synthesizeable. You can’t just >>> print “Hello world” and have it generate a UART, store a string, etc. It has more in common with traditional HDLs than C-to-hardware.

    A good example would be an NCO. It requires a counter and a CORDIC. In a traditional HDL, you would write the CORDIC as usual, then you would generate some expected simulation results and store them in a file using a scripting language (like Python or tcl).

    In MyHDL, the CORDIC and the mechanism that verifies the CORDIC are all in the same language. The limited subset of HyHDL that is synthesizeable will later be converted to Verilog or VHDL. The verification though gives you all the power of Python, so you can use math.sin() to generate your verification data for instance. math.sin() never gets turned into hardware though!

    In that way, it unifies the testing and synthesis code (the same way something like a web app would be written), and it allows you to use the very very well developed testing frameworks that already exist for Python.

    One thing related to the show:

    I am finding it very frustrating to listen to Dave constantly step on Chris without understanding what he is talking about first. It seems every show is Chris bringing up something, then Dave saying “that’ll never happen”. I have no problem with Dave criticizing stupid ideas (like chip printing 😉 ), it just seems that he criticizes before fully understanding the idea/product (the MyHDL thing is a great example). I think that Dave needs to have closer read of the list Chris prepares before the show, or he needs to stop interrupting so much. On the other hand, when there are guests on the show, I think that Dave has lots of good input.

    Sorry for the rant, overall I really like the show, I just think that would be a nice improvement.

  6. Denis says

    Dave is much more entertaining when sick with Bird flu! Just catching up to this episode; great work!