I want to collect the activity times from a machine which has no Interfaces to record the running Actions via wire. But I could put a PC with microphone close to that machine and listen to the microphone. If a certain noise Level is reached would indicate the activity, then record the timestamp until noise disappears.
Does anyone have an idea whether this is possible in Powershell and how to do it?
Related
I'm researching and trying to building a RC car that can be controlled by the internet. I've started looking into how communication over the web works, but I seem to be going nowhere. My goal for the project is straight forward:
The RC car has an on-board camera and 4g wifi router that enables communication (driving commands, video streaming) over the internet. A Raspberry Pi will serve as the on-board computer.
I will be able to control the car with my PC even across the globe, as long as I'm connected.
I want to preferably do as much by myself as possible without relying too much on other people's code.
So here are my questions:
How does an application communicate over the internet? What is the interface between the application's logic (e.g pressing "w" to go forward), and transmitting/receiving that command over the internet?
How is video data stream handled?
I've looked into WebRTC and WebSockets for communication, but they are aimed at providing real time communication to web browsers and mobile, not something like a raspberry pi, and I'm still in the blind as for exactly what technology should I use, and in general the overview and architecture of real time communication.
All I've achieved so far was an app that sends text messages between devices through a server on my network, with very primitive reading/writing using java Socket.
In short, what does messenger/skype/zoom do in the background when you send a message or video call?
Any guidance would be greatly appreciated.
First things first. You cannot do real-time control over Internet, period. There is absolutely no way to guarantee the delivery latency. Your control commands can arrive with a delay from milliseconds to seconds, or never. No way around it.
Now, you can still do a number of reasonable steps to absorb that unpredictable latency as much as possible and safe-guard your remote robot from the consequences of the unreliable communication.
For example, instead of sending the drive commands directly - as in, acceleration, deceleration, turn angle, etc., you can send a projected trajectory that is calculated from your drive commands locally on a model. Your RC car must be sufficiently smart to do some form of localisation - at the very least, wheel odometry, and with a good enough time sync between the sender and the RC car you'll be able to control the behaviour remotely without nasty consequences of drive commands executed at an unpredictable delay.
You can add a heart-beat to your protocol, to monitor the quality of the communication line, and if hear-beat is delayed or missing, initiate emergency stop.
Also, don't bother with TCP, use UDP only and maintain your own sequence counter to monitor missing packets. Same applies to the telemetry stream, not just command channel.
Currently Im building a simple collaboration room for Hololens 2, I want people to be able to see each other.
So I built a system using udp socket to share the hand of user across network (client-server).
To try proving that my system is not at fault I tried a simple experiment ,
I have 1 server and 2 clients, 1 of the client is on Holo 2 and the other on windows standalone both are connected to the server via wifi.
When both are connected they can see each other avatar as well as their own (The computer simulate hand with the MicrosoftRealityToolkit)
Inside the hololens when the user move his hand, we can see the Pc client receiving it instantly with a really small delay
however the Holo recv his own move way later (0.5s delay approximatively)
Same experiment with the pc moving his avatar, It will recv his own move instantly , however the holo will once again recv it with a delay.
Also I noticed that if I increase the messages frequency from the server the hololens will start to lose all the packets
It's really strange because all the packets are received, all the movements are well restored they just have a big delay on holo. I suppose that the networks card is at fault and buffer the received msgs, but Im not knowledgeable enough on network stuff to really understand what's happening there.
Alright so here are the couple of things you can do.
Try with TCP communication so you can keep track of the packages.
Don't send the the pose values constantly, just send when the pose changes and when you receive the data on the Hololens, perform interpolation to get a smoother results. This will make it feel like you have less lag.
Late reply to this, but hopefully helps someone:
Hololens seems to absolutely hate receiving UDP broadcasts. Was having identical latency issue, even with all other devices disconnected from the network, simple packets, and sending at a far lower framerate than the hololens. Try addressing the hololens IP only, not the broadcast address, even if it means you need a second server running for all the other devices
On the Maxim EKG chip, INT2B can be set as a peak detection trigger. How do I send a BT notification, preferably with a timestamp as soon as possible through the Nordic platform? Thank you.
In Movesense architecture there is no direct access to hardware, everything happens via Movesense API (defined in MovesenseCoreLib/resources/movesense-api as ".yaml"-files).
The Maxim 30003 peak detection is accessed via /Meas/HR -resource which gives notification each time a peak is detected. That resource can be subscribed to directly from the mobile (via the MDS library, see: movesense-mobile-lib). The delay from the actual peak to the mobile notification should be relatively constant and dominated by Maxim chips detection delay (read: I have not measured). The BLE connection causes itself some delay that should be 20-100ms or so depending on the BLE connection parameters etc. This is the way I'd go for since later when we add the timestamp to /Meas/HR (it has been requested from us already) it's a simple modification to use the included timestamp.
Alternatively you can write your own sensor app (firmware) with its own API, that can subscribe to /Meas/HR and for each notification do GET to /Time/Detailed and return just the timestamp each time a peak is detected. For a starting point for that I'd recommend the jumpmeter_app and modify it accordingly.
Full disclaimer: I work for Movesense team
I've got a guitar amp with a midi interface. I'm planning to see what's possible with the device that hasn't been built-in by the manufacturer. Since I have no experience with MIDI I'd like to know if it's possible to ruin a MIDI device by sending wrong data.
I'm not sure what data I'd like to send, and the device is basically a black box without documentation, so I can't give much more details. But one thing I'd like to attempt is overwriting the built-in effects.
MIDI commands are parsed and executed by the device's firmware.
Whatever effect(s) a command has is determined by what the firmware is programmed to do when it receives that command.
Typically, unknown commands are ignored, so it should not be possible to ruin a device by sending random data.
Most devices do no have any permanent state.
However, some devices allow upgrading their firmware through MIDI, so if you use the correct SysEx command, and manage to get any checksums correct, it would be possible to replace the original firmware with your own code (or some non-code that prevents it from working).
I am developing an iOS application that receives data through the auxiliary port (microphone).
We got oscilloscopes hooked up and are at the point where we can measure frequencies and amplitudes on a testing iPhone.
However, even with the auxiliary cable connected, the iPhone still listens to the internal microphone in addition to our external AUX input thus watering down our measurements.
The iPhone definitely recognizes the connected AUX cable (internal speakers are turned off).
Is there any way to programmatically disable the built-in microphone?
or
Is there some special signal we can send through the AUX port to disable the internal microphone?
After much research on this topic, there is no way to do it at this moment in time.
If you look at the Audio Session Programming Guide and the AVCaptureDevice Class Reference, all the properties relating to the devices input sources and audio routes are readonly.
If it's of any use, you can detect whether or not headphones or an external mic are plugged in. Here's a question relating to that.
I don't believe you can disable the built-in microphone without the user physically pressing the silent switch, but maybe you could store the data recorded by the built-in mic and then filter it out of the measurements taken by the oscilloscopes? I don't know how you would go about implementing this; it's just a theory.
Hope this helps!