I have dataQ plugged into a bunch of circuits in the lab that I use to measure Voltage V. Suddenly, I tried to connect to the dataQ in my laptop for the usual testing, but the device did not show up in the "Windaq dashboard" software. The device shows up in the device manager as "COM3". I did some research and I found out that means that the device is in CDC mode and I need it to be in LibUSB mode for it to be detected. to do that the manual says to hold on to the control button after 5s from connecting to the computer until the LED light turns red.
My problem:
I pressed and was holding the button for 1 minute but it never went red. am I misunderstanding the problem ? Any help from experienced people is appreciated.
(Note: I am using DI-4108)
I got the answer from the company itself:
keep pressing the control button as fast as possible and after that press and hold it until the LED is red
Related
I currently have firmware that can reach an average deep sleep current of ~130uA. I can reach this level reproducibly on one of the boards I have.
successful deep sleep
Trouble is, when I try to clone this chip onto other chips using the nRF Programmer (Connect) app, I get extremely high power consumption, average of ~20mA at all times, seems the device doesn't reach deep sleep properly. Tried this on several other boards, so I don't believe it's simply a problem of something shorting. Strangely, the application just runs fine, the current is just several times normal for the same functionality.
unsuccessful deep sleep
Does anyone have any ideas on how I can truly clone the flash of one device, onto another? Clearly the "save as file" on nRF Connect isn't doing this. Erasing all and reuploading, starting from a blank chip and writing,
FYI I'm using the nRF52840 module by Raytac (MDBT50Q), implemented on a custom board. This board SHOULD be capable of going down to ~33uA, which I have observed in the past with this very board. By some combination of erasing all, reprogramming, setting the 3.3V logic level(nrfjprog --memwr 0x10001304 --val 5), etc,
For posterity, I did actually find the solution! For anyone else in a similar boat to me, the winning command is:
nrfjprog.exe --readcode --readuicr --readram [filename.hex]
Apparently, the --readram was the winning flag, as without it the sketch simply doesn't run at the same current consumption for whatever reason. But now, I can reproducibly image and transfer identical firmware, which was what I was after.
I am trying to set up a simple video-call device for a senior that has absolutely no idea of technology.
The plan:
An old Laptop connected to a monitor and a USB keypad. The laptop boots up (win 7 or 10) and starts skype or zoom ( some form of Kiosk). The senior can only accept a call with on big green button. The senior can call people with a push of a button.
The Problem:
I could not find any way to make a call (zoom or skype... this would be widely accepted from other not very tech-friendly relatives) with just a key combination/ shortcut that does not include a mouse.
The solution so far (not the road I want to continue):
I made a video call device with a pi, an old monitor, just one button, and a jitsi-meet (browser)
my current setup does not enable the senior in question to actively make calls and is generally too unreliable
I am looking forward to someone pointing me in the right direction
I am a bit new here, English is not my native, so I am sorry for any possible misspelling.
I have a very odd problem - my Xiaomi Mi Surface Display 34" (XMMNTWQ34 model) monitor buttons act really strange - instead of calling the monitor OSD, pressing any of 4 present buttons tries to switch to another possible input source (this is even not their function!), but no luck: just 3 seconds of the black screen and it turns back to the initial image. Let me explain how I got into this.
I have a monitor named before, which has 4 input ports: 2 DP and 2 HDMI. There is a PC always connected to the monitor via the DP interface (DP1 to be exact). Today I tried to connect a second PC via HDMI to the HDMI1 port. It went totally good, I was able to switch between PCs using a monitor OSD. But I thought it was too long and complicated to press a dozen buttons on OSD just to change an input source, so started to google any other programmatical methods of doing such thing.
Some fact: there are no drivers for this monitor on the Internet (it actually works at full 3440x1440#144 Hz resolution/refresh rate via DP interface without any trouble, but Windows sees it as "Generic PnP Monitor", so I see no way to fix it without a relevant driver).
I have found that any VESA-compatible monitor has the 0x60 parameter, which means exactly "input source", so altering the value of this parameter switches the input source without the need to call an OSD. I have found that the possible values of this 0x60 parameter for my monitor provided by several utilities are: 0x0F, 0x10, 0x11, and 0x12. But setting any of these values got me no luck - the screen just flashed black and nothing more. Moreover, those utilities showed that the current value of the 0x60 parameter was 0x07 - described as "S-Video 1" input source, and it did not change at any made tries. But my monitor does not even have such input ports!
But I discovered a total disaster a bit later - when I tried to switch the input source via OSD, I was not able to call it - any of the 4 buttons on the monitor was causing a black flash and nothing more! So OSD is now totally unavailable! This is madness. I can't enter the OSD, I can't change the input source without turning off any one of 2 connected PCs, I can't do anything which is supposed to be made via OSD. Rebooting and reattaching of every possible thing has no effect - even with 2 PCs being connected to monitor and waiting to enter a BIOS password (no OS loaded whatsoever): pressing any button on the monitor causes only black flash and nothing more, no OSD called. I guess this is a strictly monitor firmware issue because the OSD worked well until yesterday.
I have absolutely no idea how to solve this, I googled this all day long, but no luck. System restore did not change anything. Please help. Thank you all very much.
Same issue after using ControlMyMonitor App. At the time being, i didn't found any solution to get the OSD back. And I didn't found any solution to factory reset the monitor, I don't know if it's possible.
I strongly discourage users to use any kind of VESA com application on this Xiaomi 34 monitor !
Now, the best solution in order to switch inputs, is to disconnect or shutdown one of the computer connected, ans it will switch automaticaly to the only one remaining. (Or use a VESA script...)
I have a nearly finished prototype using an arduino uno. Basically its purpose is to switch a 2000w main AC heating load using a heavy relay on and off. The input of the relay is comming from the mains but is connected to the power company using a special meter that is only switched on between 23-07 hrs at night. The power for the arduino is continous by the way, so this stays on.
The whole thing is nicely build into a box with on the front an small lcd display and a button, connected using 20cm wires to the arduino board (I am using a protoshield).
The button is pulled up with a 10k resistor which is pulled to ground when pressed. I have put a 0.47 uF cap on the input pin = pin 2 to also debounce the circuit a bit. In software I am using an interupt on the falling edge to detect button presses. The whole thing works nicely... Except...:
When the load ac input is switched on by the power company this is sometimes recognized as a button press! I am thinking that the suddon power spike induces a voltage in the 20 cm button wires which is recognized as a falling edge. How can I avoid this?
I am equiped with multimeter, oscilloscope, soldering... so I can try out any suggestions in detail.
I am having a similar problem building a fuel injection flow bench. The button press starts a simulated engine run sequence that powers a relay. That relay then powers up to 6 injectors. What happens is as soon as I press the button the injectors closing induces a current and trips the whole system to start over again. The solution I've found that worked was using a battery to supply voltage to the injectors as opposed to the power supply itself. This isolates the arduino supply from the injector supply via my relay. The problem is of course now I need to keep the battery charged. I'm looking for a more elegant solution.
I tried to solve this issue in hardware, but unfortunately failed.
These are the options I tried, but that did NOT work
used a shielded cable for the button
implemented an XY denoise capacitor network on the AC of the load (input)
like this one : http://www.conrad.be/ce/nl/product/450571/K042201052-Ontstoringscondensator-XY-Radiaal-bedraad-01-F-250-VAC-1-stuks?ref=searchDetail
In the end I implemented the following software solution:
The first time the button is pressed, it must be pressed 1 second before the button actually becomes active. This will never happen due to the AC turning on because this is a very brief spike. I programmed this into the arduino using interrupt to detect button press and then micro delay (inside the ISR) to check that after 1 seconds the button is still pressed.
After the initial 1 second button press, the button stays lively for 1 minute
I'm new to iBeacon, and would like to simulate entering and exiting an iBeacon region, to see how notifications work on entering/exiting a region when an app monitoring for iBeacons is in the background.
The iBeacon I'd like to try this with would be a virtual iBeacon, running on a mac or an ios device.
Can this be done by fluctuating the power or is there a better way to do it? And are there any good examples of doing this anywhere?
The easiest way to do this is by simply turning the iBeacon on and off. I do this every day using our MacBeacon and Locate for iBeacon test tools which have on-screen on/off switches.
In theory, you could do what you suggest by turning the radio power way down, too. But iOS, OSX and Linux do not let you adjust the radio power. Turning off the transmission completely is an easier and simpler alternative.