Jim (JR)

Member Since: November 24, 2012

Country: United States

  • @nate

    1. Interesting!

    2. I've worked with government agencies and various certification processes before, (but not the FCC), so "ah feel yer pain!"

    3. I appreciate the time and effort you put into getting this device certified. Many other companies would just punt, say it's a subassembly, and leave the end user to certify it themselves.

    4. This whole series on the Artimus and the efforts you folks put into it is extremely interesting in its own right.

    The next time I have a client who thinks that RF certification is just a matter of filling in an application, writing a check, and stuffing everything in an envelope, ("Really now, how complicated can that POSSIBLY be!!"), I'll just point them to your article and watch their jaw drop

    Thanks again for such an awesome job!

    Jim "JR"

  • You said: "What sets the RED-V RedBoard apart from the rest is the completely open-source approach from hardware to ISA. That means anyone can make full use the microcontroller without requiring royalties, licenses, or non-disclosure agreements."

    Apparently not true?

    On your page located at: https://learn.sparkfun.com/tutorials/red-v-development-guide, there is the warning:

    " Warning: Do NOT attempt to reprogram the NXP K22 ARM Cortex-M4. It has proprietary Segger firmware flashed onto the chip, which allows it to upload programs the SiFive Freedom E310 core. Reprogramming the NXP K22 ARM Cortex-M4 will overwrite the firmware and you will no longer be able to reprogram the board. To replace the firmware, you will need to purchase a license from Segger along with one of their programmers."

    So, it appears to me that this may not be "completely open" as the boot loader is proprietary. Or am I missing something here?

    Thanks!

  • I'm not a python programmer, (yet!), so I might be talking nonsense here, but is it necessary? Aren't you able to control the micro:bit with the python libraries that already exist for the micro:bit? If that is true, can't you control the micro:bot board in the same way?

    My apologies if I am not understanding something here.

    Jim "JR"

  • Suggestion: Because the robot kit is called the "micro:bot" there should be a link to the extensions called "micro:bot" At the very least there should be an alias linking "micro:bot" to "moto:bit".

    Why?

    I suspect that many people will remember that the robot is named the "micro:bot" - less will remember that the extension is named after a specific circuit board. At least I get confused every time I try to use the robot with Make Code and have to look it up.

    An additional point, the vast majority of robot kits (that result in a moving, active robot) - as opposed to robot boards, (that can be made into robotic devices with the addition of additional parts) - are named after the kit instead of the circuit board.

    Since you sell both - the board and the kit, maybe it should be listed under both names?

    What say ye?

    Jim "JR"

  • The particle pricing link is broken when I checked 11/23/18. Can you provide an updated link please?

  • +1 - totally agree! Nothing frustrates me more than a potentially interesting article that is some sloooowly paced video that takes five minutes to download and doesn't say anything more than a short paragraph would.

  • Reminds me of the time my wife and I visited the Grand Canyon. Looking across the canyon, your mind really can't "get its arms around" the sheer magnitude of it. That is until you almost don't make out some nearly invisible specks on the opposite face. . . When you realize that those nearly microscopic specks are people on a viewing platform, the real scale of the magnitude snaps in and your jaw drops off the edge of the cliff!

  • Greetings!

    I am trying to create a traffic sensor / data-logger using sensors like this.

    I want to place a sensor on one side of a street, and a piece of reflective metal on a fence opposite the sensor, that's about six-or-so meters away. I want to detect either an object closer than the fence, (usually by a factor of two), or an interruption of the beam, (in case the vehicle is a truck with non-reflective fabric sides - or has such a horrible paint-job that the beam doesn't reflect.)

    This will be used out of doors, so ambient light is a serious concern.

    I don't need millimeter accuracy. In fact, I was originally considering a simple IR emitter/detector sensor pair bouncing off a reflective surface. The easy-to-assemble Qwiic systems sound like an answer to my prayers without having to re-design the wheel.

    Question: Which, of the many sensors you sell, would be a good fit? (Hopefully not the Garmin sensor for $150-or-so!)

    Thanks!

    Jim "JR"

  • I can understand everything about the kit from the description, except for the small PCB with eyes. Since it's a PCB with a few components attached - aside from the googly-eyes - it's obviously there for a purpose, What purpose?

    I've seen different illustrations showing the "eyes" pointed in different directions. Is that part of the robot servo controlled somehow? Or is it just a friction mount that can be moved by hand one way or the other?

    Is it possible for this to be clarified within the description?

    Thanks!

    Jim "JR"

  • @emc2

    There had better be a damn good reason for somebody to use more than 5V in a USB port… if they did, a looot of people would be reporting burnt devices.

    This is only true for the USB 2.n protocol. USB 3.n (blue plastic insert instead of black), is rated to supply a max of 20+ vdc, as the 3.n spec makes provision for driving devices that are much more power hungry than your run-of-the-mill 2.n device. (http://www.usb.org/developers/powerdelivery/)

    In fact one of the bullet points on that page reads like this:

    • Increased power levels from existing USB standards up to 100W (No, that is not a typo! Imagine, USB powered space heaters!)

    The same thing is also mentioned at this site:

    http://www.electronista.com/articles/11/08/09/usb.30.power.delivery.spec.to.allow.up.to.100w/

    I have an ASUS TF-201 tablet that has a USB 3.n charger that supplies 15 vdc charging voltage to the device.

    One thing I do not know (but strongly suspect), is if this particular charger, (or USB 3 in general), can detect and supply the correct voltage to the device. I wold not be surprised if USB 3.n can do that, as all it would have to do is put the rails at +5, interrogate the device and receive voltage info, and then adjust the positive rail to match the requested voltage.

    I also strongly suspect, but do not know as a fact, that USB 2.n (or earlier) devices communicate in such a way that the 3.n interface automagically falls back to 2.n, since I have no devices that have a USB 3 host port.

    @everybody Thanks for the info!

    p.s. If I understand the LiPo spec properly, just so long as the battery you are charging can accept a charging current of 500ma or more, this should work like a charm. The only difference is that devices that can accept a larger charge current will take a correspondingly longer time to charge at 500ma.

No public wish lists :(