Member Since: February 16, 2011

Country: United States


Spoken Languages

english français castellano

Programming Languages

asm X86 C C++ Pascal PHP SQL


http://www.dplomat.com http://www.jmd-tech.com

  • In fact you can use whatever for the second to last byte, but there are some restrictions on the first byte: the two lower bits are flags for global(vendor ID)/local(arbitrary) and unicast/multicast.

    The second digit should be even to have an unicast address (bit0 = 0) Otherwise it will sometimes work on a direct link PC <-> Arduino but not with some ethernet switches between.

    Also to be more standards compliant i set bit1 = 1 for local address. This one is not critical, it would just prevent the very unlikely conflicting with an actual device, and also avoid some network scanner/mapping tools to identify your Arduino as an HP/Cisco/3Com device or whatever the vendor-id part of the MAC would happen to belong to.

    To sum-up the first byte should end by 2, 6, A or E. (used 0xDE in my case)

    Here is the detailed explanation i’ve had on actual testing: http://www.incrediblediy.com/2013/03/arduino-based-webserver-atmega328.html?showComment=1483930305539#c4443782262393030090

  • Zooming on the picture on the page of the PoE shield, we can read HanRun HY931147C on the magjack. Supposing it’s the actual part, i’ve found a datasheet here: http://www.knap.at/datenblaetter/ste/ste_han_hy931147c.pdf

    I’d be interested in buying some dozens if you could confirm it’s really this part. Also searching for other PoE magjack models it appears there are some other with compatible pinout, sounds good news, as i’d like to have a reliable not too hard sourcing of parts for a current design i’ll be extending and integrating into larger products.

    – UPDATE 2017-05-20: I’ve received 12 of those i’ve ordered, like in the picture on this page no marking on case, but i’m pretty confident they’re actually HY931147C: Testing them with multimeter shows R(p2.p1)~=R(p2.p3)+R(p3.p1), same for p6.p4.p5, and a diode test on p9 and p10 shows no current one way, and 1.2V forward drop the other so it seems they also have the integrated diode bridges. Saving PCB estate of 2 DA4X106U0R or MB1S and associated traces :)

    The datasheet doesn’t mention max current for those diode bridges, so i’ll sacrifice one for a max prolonged-load testing when i’ve returned to my lab and etched some breakouts (For those using KiCAD there is a footprint for this part in freetronics_kicad_library)

    – UPDATE 2017-05-22: Well, made 6 breakouts for those, and testing with some passive PoE injector i have the voltage present on P9 and P10, except the polarity is reversed compared to the HY931147C datasheet, i have + on P10 (outermost) pin and - on P9. To confirm the diode bridge is working well, i built a PoE injector with reversed polarity from an old RJ45 wall socket, at least the diode bridges are ok, as i still have +P10 and -P9. So either there’s an error on the datasheet, or we have the nasty situation of 2 existing parts, one with no marking with exact same footprint but reversed polarity… will try to get somewhere one with the marking HY931147C to check if it’s an error on the datasheet or really two different parts.

  • I’ve got some of those i bought about 15 years ago at a local dealer, both N/O and N/C versions.

    The one on RS picture looks like my N/O versions (plastic inner cylinder of pushbutton) while Sparkfun’s one looks like my N/C (metal inner cylinder)

    At the time i preferred the N/C that are very sensitive while the N/O needs to have the button pushed on its full course to be on.

    I had those stored in unoptimal conditions (humidity), and while the N/O degraded (needs some force to close the circuit and huge contact resistance varying with push-force), i was surprised to find the N/C kept all their binary and responsive touch, maybe N/C contact are somewhat more moisture-resistant.

  • I suppose the way to go from Arduino would be:
    -use Ardupilot code
    -convert to plain C++ AVR code with Makefiles etc
    -generalize a bit the hardware handling code “drivers” for gyro/accel/compass (maybe an intermediate step would be Ardupilot ported to Arduino + 9DOF IMU, I’m in the process of doing this as i’ve got one but have very few spare time…)
    -port the code to LPC2148 MCU
    About the servos, either you must use digital servos conneted to I²C but that would mean much wiring in I²C, not toot good for using the bus with fast sensors, an I²C IO expander or soldering wires to GPIO pins and implement PWM.
    If one day I manage to have 9DOF IMU + Ardupilot working well I might upgrade to this awesome unit as the HW specs of the ATmega (2k SRAM!!) is the next obvious limiting factor

  • looks like space-wise the Li-Ion is better, but when weight matters LiPo is better

  • Maybe a bit overkill for this use, but it can power a chinese bluetooth mouse for two full days of intensive use:
    review and upgrade of 6D rechargeable bluetooth mouse

  • I’ve just received mine some days ago, was the first time i play with I²C devices.
    I’m using an Arduino board with a protoshield, makes a very straightforward prototyping platform with a large community so there are a lot of examples on the net for reading I²C devices and printing the output to serial (in fact serial over USB) console text.
    Makes it an easy trasition to standalone ATmega TQFP32 platform when you have a production-ready design (and lightweight requirement i suppose)
    I’ve found this for the accelerometer:
    I’ve adapted it a bit to read also the gyro and compass values.
    Now those are raw values but i’m in the process of writing a small unit to init at optimal settings and output values as SI units.
    For the Open Log i just cheched it’s page and i can only backup Nate’s reply to your comment, neither hard nor trivial.

No public wish lists :(