5
\$\begingroup\$

I have this A118 dashcam, which I want integrate with a Pi.

I wish to record onto it mounted SD card when driving, and once home within WiFi range, to download the files on the SD card through the Pi to my home network.

This camera, when connected to a 5 V source on my vehicle's cigarette lighter, the camera begins recording right away.

When I connect it to my computer, it prompts (on the dashcam screen) whether to operate in "Mass Storage" or "PC Camera" mode.

This video shows how a problem of a different camera was fixed by insulating the TX and RX terminals from the connection.

How does the camera (or a regular USB device, like a phone too) know whether it is connected to a simple power source or to a computer?

Also, how could I then use this fact to control the dashcam, so when out of my Wifi range, it records as it would when just power is supplied, and when in Wifi range to revert to "Mass Storage" so the Pi can access the video files and transfer them.

I guess relays would work, but their large size does not make it practical. Would optocouplers be a better alternative, or are there other suggestions I may look into?

\$\endgroup\$
  • \$\begingroup\$ I were thinking about the same thing earlier while driving home from work. I think it may be better to just use a dash cam which supports this in the first place. Although it would need to be hard wired low voltage protection buck converter. \$\endgroup\$ – user2924019 Apr 10 '18 at 18:50
7
\$\begingroup\$

The USB Battery charging specification is used by many USB devices to determine what type of port they are attached to.

The main types of ports are...

Dedicated charging port: The charger indicates that it is a dedicated charging port by shorting the D+ and D- lines together.

Standard downstream port: A USB port that supports up to 500mA of charging current (for a USB 2.0 port), plus USB data. The device enumerates on the USB bus to determine how much current it can draw. The bMaxPower field in the USB device descriptor is used to ask the host for power.

Charging downstream port: A USB port that supports up to 1.5A charging curret, plus USB data. The device determines that it is attached to a CDP by first toggling the D- line. If the D+ line tracks the D- line then the device knows it is attached to some sort of charger. Next the device does secondary detection by toggling the D+ line. If the D- line stays low then the device knows that the lines are not shorted together so it must be attached to a charging downstream port.

http://www.usb.org/developers/docs/devclass_docs/batt_charging_1_1.zip

|improve this answer|||||
\$\endgroup\$
  • 1
    \$\begingroup\$ A standard 12 V to 5 V car USB converter would be a dedicated charging port correct? Which I could easily implement with the mux suggestion in the other answer by connecting the D+ and D- lines? \$\endgroup\$ – A.S. Apr 10 '18 at 14:13
  • 1
    \$\begingroup\$ Yes a 12V to 5V adapter is a dedicated charging port. \$\endgroup\$ – user4574 Apr 10 '18 at 14:15
  • \$\begingroup\$ @user96037, not necessarily, some car adapters can have Apple charging signature, which is very different from China DCP signature. \$\endgroup\$ – Ale..chenski Apr 12 '18 at 17:02
  • \$\begingroup\$ -1 Description of the Standard downstream port is upside down. A device "doesn't enumerate", it is the USB host that attempts to enumerate a device.The device doesn't "determine now much current it can draw", it is the USB host who determines if it has enough power in its budget to ALLOW the device to operate. The bMaxPower field is to INFORM the host about potential power consumption, although one can construe this mechanism as "asking". \$\endgroup\$ – Ale..chenski Apr 12 '18 at 17:12
  • \$\begingroup\$ @AliChen I have read a good portion of the USB specifications and I think my description was accurate. My explanation may have been unclear to you when you read it. When I said that the device "enumerates" I only meant that it participates in the process of enumeration which is controlled by the host. I never said that the device controls the enumeration process. Also, I am familiar with how device descriptors work. I was careful to say that the bMaxPower field is used by the device to "ASK" the host for power. The host can always decide if it wants to allow that device have it. \$\endgroup\$ – user4574 Apr 16 '18 at 2:17
5
\$\begingroup\$

To be very concise, USB devices make use of the D+ / D- lines to detect whether or not they are connected to a USB host or a charger.

If you wanted for the device to alternate between the two modes you described, I could suggest using an USB 2:1 mux IC such as FSUSB43 wired to gpios of the Raspberry Pi. Something like that:

enter image description here

As @dwizum pointed out in the comment below, you would also need to add a transistor on the 5V VBUS line running to the dash cam to power cycle it, as switching D+ / D- only might result in undefined behavior. To simplify, power cycling the VBUS line to the USB device when switching will force it to be ready for a new discovery.

From there you could easily write your own scripts running on the Raspberry Pi changing the states of those GPIOS, maybe with the help of WiringPi, based on different events such as the list of Wi-Fi access points available.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ In this case, could the D1+ and D1- connections just be left floating? Or are they connected (to GND for example) in a traditional charger (although I don't expect this is the case)? \$\endgroup\$ – A.S. Apr 10 '18 at 14:01
  • \$\begingroup\$ I would strongly recommend to tie them to the D+ / D- lines of the usb car charger, as even though they don't actually transfer data, they might still be used by the car charger to advertise how much current it is capable of providing to the dash cam which I presume requires more than the default 500mA to run. See this overview of the USB Battery Charging Revision 1.2. \$\endgroup\$ – Nicolas Schurando Apr 10 '18 at 14:15
  • 1
    \$\begingroup\$ Just a comment - switching the dashcam data pins between the two USBs (Pi vs car charger) without also switching the dashcam USB power pins may not work or may result in weird behavior: as far as I know, there is no standard protocol for swapping USB data pins to a new host while the power pins are kept live. Someone can correct me if I'm wrong. Powering it down, switching the data pins, then powering it back up will initiate the handshake again and allow it to recognize the switch. \$\endgroup\$ – dwizum Apr 10 '18 at 16:13
  • \$\begingroup\$ Indeed, thanks for pointing it out. I've edited my answer accordingly. \$\endgroup\$ – Nicolas Schurando Apr 10 '18 at 17:03
3
\$\begingroup\$

How does the camera (or a regular USB device, like a phone too) know whether it is connected to a simple power source or to a computer?

USB has 4 connections: 2 for the 5 V supply and 2 for data.

A power adapter generally does not respond to signals on the data lines (with the exception of fast charging protocols but that's more level detection than data being transferred).

A PC does respond to signals on the data lines. The camera can request a USB connection and then the PC will grant that request (or not). Some information will be exchanged.

So basically the camera just "talks" over the USB data lines as soon as it detects power on the USB input. If there's no response it must be a "dumb" power supply. If there is a response it must be a PC (USB host).

Controlling the behavior of the camera depending on WiFi being in range is something that could be done by the software (firmware) running inside the camera. In general you cannot and should not change this. Get it wrong and the camera will become useless (inoperable).

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ I was just about to start writing my answer when this popped up! Pretty much covered everything I was gonna say! +1! \$\endgroup\$ – MCG Apr 10 '18 at 13:35
  • \$\begingroup\$ So is the device the one which initiates communication, and when it receives a reply it knows it is a computer? I do not intend on messing with the firmware, I don't have a clue how. What I want to do it control the connection so when the Wifi status changes, the camera resets, with the TX RX connected when in range, and disconnected when out of range. How could I do this? Or is there a reason why this might not work? \$\endgroup\$ – A.S. Apr 10 '18 at 13:45
  • \$\begingroup\$ That part of the question in my opinion falls in the category "I want something complex but have no clue how to do it and I have no experience in electronics either". Your first step should be to make the RPi toggle an IO pin depending on if the network is there or not. Then control a relay with that IO pin signal and switch the USB on/off. I would recommend a relay as doing the USB switching with electronics will require some chip, it is easy to screw-up the USB signals so that it does not work anymore or damage the camera. \$\endgroup\$ – Bimpelrekkie Apr 10 '18 at 14:02
  • 1
    \$\begingroup\$ The network and other parts of such a system is just background information, people tend to ask for it so they better know what exactly a question is about. My specific question in this case was how to change the communication between the Pi and the camera. As the other answers pointed out, I'll use a mux to switch between the Pi and shorted D+ D- lines. \$\endgroup\$ – A.S. Apr 10 '18 at 14:21
2
\$\begingroup\$

You can try to disable/enable the Raspberry's USB ports depending on whether or not you want the camera to detect a data connection,

To shut off power on USB ports (this shuts power on ethernet as well):

echo '1-1' | sudo tee /sys/bus/usb/drivers/usb/unbind

To turn power back on

echo '1-1' | sudo tee /sys/bus/usb/drivers/usb/bind

(https://www.raspberrypi.org/forums/viewtopic.php?t=172313#p1217773)

IIRC, at least on old Pi's this would not shut down the power lines of the USB ports but only the power to the USB/Ethernet chip of the Pi, effectively disabling any and all communication and enumeration on those USB/Ethernet ports; a device connected to one of the disabled ports will not be able to detect it is connected to anything other than a USB power source.

|improve this answer|||||
\$\endgroup\$
1
\$\begingroup\$

USB devices (and dashcams especially) are intelligent devices. When they are connected to USB host, the host performs enumeration and issues all other USB interface activities. And a USB device makes note of this.

When connected to a dumb charger, there is no USB enumeration/communication. That's how the dashcam/whatever knows the difference.

Regarding the actual problem, why the dashcam doesn't record internally when plugged to functional USB host, this is a question of dashcam software design - it is designed that way. Obviously when you cut D+/D- wires in the PC-to-dashcam connection (not Tx and Rx !!!), USB communication ceases, and the dashcam goes into the standard charger-powered mode.

|improve this answer|||||
\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.