In the official datasheet for the Google Coral USB accelerator (https://coral.ai/docs/accelerator/datasheet/), they mention two LED behaviors - LED on (solid) and LED pulse (breathe).
However, apparently, there are more LED modes.
For example:
https://github.com/google-coral/edgetpu/issues/675
https://github.com/google-coral/edgetpu/issues/476
So, does someone know and have a complete list of these different blinking modes with their meaning?
Related
I'd like to reduce idle power consumption on the Google Coral Dev Board anyway I can by turning off USB/ethernet/HDMI/LEDs etc. I'm struggling to find much information for how to do this. I've searched through i.MX8M documentation, and have tried similar approaches like you would do with a Raspberry Pi but obviously these aren't the same and I've struggled to find corresponding locations in /sys/.
Can anyone recommend documentation or give advice on how to turn off these components from the terminal?
I'm not sure if those parts can be turn off, but if power is what concerns you, you can try turning on this option:
CONFIG_IMX8MQ_PHANBELL_POWERSAVE
in the kernel's defconfig.
You can follow this answer to see how that is done :)
I would like to use the PRUs of my Beaglebone Black. I 've been following several tuturials from the internet whithout any significant success. Most documents are outdated because the bone_capemgr is no longer supported (at least from what I understood). So how can I use the PRUs in combination with one of the Linux systems provided by beaglebone.org?
A programmable real-time unit (PRU) is a fast (200-MHz, 32-bit) processor with single-cycle I/O access to a number of pins and full access to the internal memory and peripherals of the BeagleBone (http://beagleboard.org/pru).
There are many tutorials online for PRU coding on newer beaglebone images.
I would suggest you to get familiar with the PRU Libraries and then try some simple and recent blink code or follow some example of remoteproc usage.
I am new to ESP8266 and started just building basic devices using it. However I am using USB 5V wall adapter as nodeMCU has USB UART converter to 3.3V.
If I want to make it battery powered what is simple , small ( in volume so that it can fit along with nodemcu and sensors in a small case) and economical approach that keeps my nodemcu still safe?
-One option I can think of is to connect a Li-ion battery of 3.7V to VIN.
-Another one is to use bigger voltage and use a converter to convert it down to around 5V and then use that to connect to VIN.
Please let me know if this works ? else if there is any better option please do suggest. Also if you are referring to any items/products please help give the exact model numbers so that I can search on internet to consider buying them.
Lastly I am not much aware of electric circuits & terminology yet ( learning them), so please help explain me in basic terms possible.
Ps: this question was seen on stackoverflow some times but I couldnt find one single consolidated answer and am confused by it. Appreciate your understanding.
Thanks,
Sridhar.
This really would be better suited for the electronics sister site or a esp8266.com forum but for what it's wort here's my input.
IMHO the most convenient option you have is to buy a devkit with a LiPo connector. I recommend a WeMOS D1 mini plus a fitting battery shield. An alternative is the Adafruit Feather HUZZAH.
It can sometimes be a bit of a challenge to find the right connectors for those boards. Gotcha! different revisions of those boards might use different connectors. Currently the WeMOS battery shield uses a 2 pin JST PH 2.0mm.
No, you cannot power a NodeMCU using a 3.7v li-ion battery directly. A fully charged Li-ion battery outputs a voltage of 4.2v. The NodeMCU board has a (5v and above) vin slot along with two 3.6v slots. If you directly connect the battery to the 3.6v, it may fry the NodeMCU board. So typically, there are 3 ways you can connect the battery without frying your board in this scenario:
You can use a boost converter to convert the 4.2v output to 5v. Then connect it to vin. This will draw more current and battery discharges quickly (eg: MT3608 step up boost converter).
You can use a buck converter to convert the 4.2v to a steady 3.6v (eg: LM2596 step down converter).
Finally, the most efficient way is to connect a 3.3v LDO in middle. The difference between using a buck and LDO is, buck provides a constant and steady 3.6v output, where as LDO's output depends on the input voltage from battery (eg: S111733PI).
I have seen several projects now which derive novel spatial information from radio data collected from a typical wireless router:
http://wisee.cs.washington.edu/
http://www.extremetech.com/extreme/133936-using-wifi-to-see-through-walls
The idea of using a wireless router as a sort of passive radar is fantastic.
I am very interested in experimenting with data collected from a wireless router myself, but there is little information on how to go about actually interfacing with a wireless router and getting a raw stream of information collected by the device. Similar questions have been asked on here before, but I am yet to see a satisfactory answer.
I don't have the rep points necessary to link to the other questions but see:
'Capture Raw Signal from WiFi card as You Would a Sound Card'
'raw wifi “signal data” access'
I am looking for a solution that would let me use a low-cost device such as the oh so common WRT54G wireless router. If your answer involves custom radio hardware, you needn't bother posting.
As far as I know, the only option using a commodity hardware is to use Intel 5300 Wifi card. You can get the complex CSI (amplitude and phase info therein) from the three antenna on it from a sample of subcarriers (OFDM). You can take a look at this site:
http://dhalperi.github.io/linux-80211n-csitool/
If you read the wisee research paper you will find the platform they use for the system, it is USRP N210 from Ettus plus GNU radio software.
So it is not your usual WiFi AP they are using but the SDR solution this question also hints about.
WiFi devices are build to handle physical layer in silicon and the monitor mode is the best thing you can get without going the SDR path. You can get quite a lot of information from it - the radiotap header contains for example received signal strength and receiving antenna information. But if you really want to explore physical layer of WiFi then commodity hardware is not going to cut it.
I am importing a source code for stereo visions. The next code of the author works. It takes two cameras sources. I have two different cameras currently and i receive images. Both works. It crashes at capture2. interesting part is that if i change the orders of the webcams(Unplugging them and invert the orders) the first camera it will be the second one. We it doesn't work? I tested also with Windows XP sp3 and Windows 7 X64. The same problem.
//---------Starting WebCam----------
capture1= cvCaptureFromCAM(1);
assert(capture1!=NULL); cvWaitKey(100);
capture2= cvCaptureFromCAM(2);
assert(capture2!=NULL);
Also If i use -1 for paramters the just give me the first one(all the time).
Or any method to capture two camers using function cvCaptureFrom
Firstly the cameras are generally numbered from 0 - is this just the problem?
Secondly, directshow and multiple USB webcams is notoriously bad in windows. Sometimes it will work with two identical camera, sometimes only if they are different.
You can also try a delay between initialising the cameras, sometimes one will lock the capture stream until it is sending data, preventing the other being detected.
Often the drivers assume they are the only camera and make incorrect calls to lock up the entire capture graph. This isn't helped by it being extremely complicated to write correct drivers+fdirectshow filters in Windows
some mother board can not work with some usb 2.0 cameras. one usb 2.0 camera take 40-60% of usb controller. solution is connect second usb 2.0 camera from pci2usb controller
Get 2 PS3 Eyes, around EUR 10 each, and the free codelaboratories.com SDK, this gets you support up to 2 cameras using C, C#, Java, and AS3 incl. examples etc. You also get FIXED frame rates up 75 fps # 640*480. Their free driver only version 5.1.1.0177 provides decent DirectShow component, but for a single camera only.
COmment for the rest: Multi-cam DirectShow drivers should be a default for any manufacturer, not providing this is a direct failure to implement THE VERY BASIC PORPUSE AND FEATURE OF USB as an interface. It is also VERY EASY to implement, compared to implementing the driver itself for a particular sensor / chipset.
Alternatives that are confirmed to work in identical pairs (via DirectShow):
Microsoft Lifecam HD Cinema (use general UVC driver if you can, less limited fps)
Logitech Webcam Pro 9000 (not to be confused with QuickCam Pro 9000, which DOES NOT work)
Creative VF0220
Creative VF0330
Canyon WCAMN-1N
If you're serious about your work, get a pair of machine vision cameras to get PERFORMANCE. Cheapest on the market, with german engineering quality, CCD, CMOS, mono, colour, GigE (ethernet), USB, FireWire, excellent range of dedicated drivers:
http://www.theimagingsource.com