How would I detect a keypress inside of GNURadio, or even more specifically how would I change a variable if a key is down or up?
[Edit]
Example: A push to talk on a SDR driven HAM radio station thats using GNUradio, so when I press 'V' (on my keyboard) I transmit, this could be done by changing the value of a variable, which is used in a selector to select between a null source and an audio source
It depends on the event that you are waiting for. For example if your variable can take one of two values and you just use QT pushbutton to toggle between them, then you may list these two values in some variable and use pushbutton as an index to it, this flowgraph demonstrates how to toggle signal source frequency using a pushbutton.
https://drive.google.com/open?id=1PXb9755C4iGBOYHwXZytHH-TnmmELPpg
But if your event is waited from another process, then I recommend you to use zmq to do RPC, or even xmlrpc(client/server).
you can find a very good example of how to use zmq in /usr/local/share/gnuradio/examples/zeromq.
I hope this helps.
Related
I have created two vi's in LabVIEW: one to acquire serial data and another to plot the acquired data on an XY graph.
The second VI gets called when a Value Change event occurs on a button in the first VI. But the problem is that when the second VI is called the first VI suspends its operation, hence the values don't get updated.
Is there any solution for this?
First VI block diagram:
First VI front panel:
Second VI (ALL DATA) block diagram:
Well, you are doing some nasty stuff with global variables. This works but is not considered as good practice. (Have a look at queues and notifiers). Further, I don't see how your data gets written to those variables...
In any case, put your 2nd VI in a separate while-loop and schedule it to about 100ms (that is usually enough to update front panels or to interact with users. I'm not sure if your button-event is the right way to go. That is exactly because, the second VI waits for the callback. Just use a simple button and a true-false case to let the second VI keep running (this should even be the solution if you don't want to move the case to a second VI). Just make sure that you change the mechanics of the button to be a switch because you're checking its value not at infinite speed and you want to ensure that it gets caught every time, you click it;)
You will need to use the VI Server functionality. The exact method has changed over the years, but I believe the current recommended implementation is to use 'Start Asynchronous Call'
There is an example that you can view using the example finder. To open the example finder navigate to Help>Find Examples. Then select the 'Search' tab and search for 'asynchronous'. Finally select the VI called 'Asynchronous Call and Forget.vi'
There are other variations for asynchronous implementations, but this is probably a good place to start.
I have not done this since long ago in NeXTStep and seem to remember that you could create objects which could be made part of the event loop and could generate events that were co-equal with those from mouse and keyboard events. But... that was 20 years ago and I may have confounded it with something else.
In my particular case, I need a listener that checks a select() to see if one of many UDP ports have received a DGRAM. I need this to happen without disturbing the mouse and keyboard events, although it would be nice if I gave the UDP check a higher priority.
Basically, I have streams of numbers from one or more other systems that are to be displayed in a GUI, and I want the user to still be able to use buttons and such.
According to the cocoa events guide you can raise an event with type NSApplicationDefined.
[NSEvent otherEventWithType:NSApplicationDefined location:modifierFlags:timestamp:windowNumber:context:subtype:data1:data2:]
As for how to raise them, I'm not exactly sure what you need, but this post on the apple developer lists shows how to register a UDP listener. It raises a notification via NSNotificationCenter, but you could make that an event.
What is the best way to understand a complex LabView VI that controls a motor?
My goal is to control the motor from a joystick.
The wiring diagram shown below allows a LabView user to control the motor from the LabView GUI: move a slider up and down either increasing or decreasing the desired velocity. As the slider's value changes, it is fed into a bunch of math controls and eventually gets converted into a command string for the motor to interpret. This command string, if I understand correctly, is bunch of bytes that get written to the serial port.
Instead of using the LabView GUI to control the motor, I would like to use the joystick.
What is the best way to approach this?
The joystick has pitch,yaw,roll,and throttle. Which one relates best to the velocity of a motor?
The answer to your title "What is the most efficient way to quickly understand how a complex LabView VI works?" is probably to do some combination of the following:
Look at the VI's inputs and outputs to try and understand what they are there for. The label and caption of controls and indicators may be helpful, also right-click to check the description and tip.
As well as controls and indicators, look for other I/O: queues, notifiers, global variables, file read/writes, instrument communications, and for any data storage that persists between calls such as an uninitialised shift register.
Look at the overall structure of the VI to see how it executes, e.g. is it a one-off operation, does it execute different cases depending on some input, does it loop until a certain condition happens, does it use a state machine structure, etc
Break down the VI's structure into smaller pieces that you can understand. You could print the diagram out and annotate it by hand, or add frame decorations and text comments to the diagram to record what you deduce. If the diagram is cluttered or poorly laid out, rearrange it as you go along (use Ctrl-click and drag on the diagram background to add blank space where you need it).
Set probes on key wires and watch them while the VI runs to see what happens
If possible, manually set the VI's controls to example values and run it to see what happens (this may not work if the VI depends on other parts of a program running at the same time)
Write a test wrapper VI that calls the complex VI and supplies it with example data or inputs to see what happens.
To address your specific question about the VI diagram you've posted, I can see various controls for quantities such as Velocity, Position, Amplitude, Max A (amplitude?), Frequency and so on. You need to decide which of these quantities should be controlled by which axis or output of your joystick. Then you need to add code that reads those values from your joystick, and modify the existing code so that the parameters you want to control are supplied by the joystick values instead of the front panel controls. You could probably just put the joystick reading code inside the existing loop, wire the joystick outputs to join up with the wires from the front panel controls you want to replace, and then change the relevant front panel controls to indicators from the right-click menu so that they will show the values you are getting from the joystick.
The best way is to write one from scratch. But you could analyse the code by clicking the Highlight Execution button to display an animation of the block diagram execution when you run the VI, and use probes to check intermediate values. And you probably should also do an on-line course, e.g. LabVIEW Training: Learn LabVIEW in Three or Six Hours
My answer to your third question is "throttle.".
I have a Windows Application in VB.NET. I want to know if a value is entered by a user via the keyboard, or if it is coming from a barcode reader. I want to store values that come from
the keyboard in a different database than the ones the come from the barcode reader.
Option 1:
Get a barcode-scanner that is connected to a serial-port (raw serial device read by a COM port). As most barcode-scanners emulate keyboard strokes there is no way to directly distinguish a barcode scanner input from a keyboard input (see next option) without going low-level (see last update).
One connected to a serial port (or emulated one via USB as serial-ports are not so common anymore) gives you full control on where the input comes from.
Option 2:
Count number of chars typed by time. Barcode-scanners inject a sequence (line) pretty fast compared to typing. Measuring the time used in the textbox by counting key-presses (use CR+LF as a measure point as these are sent by the scanner as well) can give you one method to distinguish if a human is typing (unless there is one typing fast as f) or the content was injected. If timed-out just reject/clear the input.
In addition the checksum of the barcode (if you use one that contains that) can be used to do an extra validation in addition to time measurement.
(you can detect pasting by overriding the ctrl + v as in the next option).
Option 3:
Combine option 2 but instead of measure in the textbox tap into the ProcessCmdKey() function (by overriding it) and measure there if textbox has focus. This way you can first buffer input, measure time and if within a set time-out value, inject the line into the textbox.
Option 4:
This might be a good option as well:
http://nicholas.piasecki.name/blog/2009/02/distinguishing-barcode-scanners-from-the-keyboard-in-winforms/
Option 5: a non-technical approach -
Usability improvements: make it visually very clear that bar-codes must be entered with a scanner and not typed. I am including as an option as it is simple and if made correct also effective (there's no right answer of what is correct unfortunately).
Approached could include f.ex. a watermark in the textbox ("Don't type, scan!" or something in that order). Give it a different color, border, size etc. to distinguish it from normal textboxes, and have a help text associated and available at all time that improves clarity.
How can I bind a key combination to my vb.net application? I know it has SOMETHING to do with the registry, but I have no earthly idea what or how to go about doing this. I want the user to be able to hit those keys when the app is open and have it execute my function, but not while the app is closed.
Thanks for the help!
If you are using a dialog, then you can put '&' into the text for some controls (buttons, checkboxes, radio buttons, etc) and this will cause Alt plus the next character in the text to be used as an accelerator/shortcut. i.e. "&Open" would activate the Open button if you press Alt+O. "Op&en" would activate if for Alt+e.
Beyond that, as Jason Irwin said, you need to add an event handler to your Form for KeyDown or KeyPress events, and then check if the keypress is the key combination you are interested in. This will only work if the user activates your form (clicks in it to give it the input focus. If they put it behind another window, it will not react to the key presses)
If you don't want to show a form, or want to react to keypresses when you're not the input-focus application, then it gets a bit more complicated (you either need to use a hidden form or a keyboard hook)
edit
OK, it looks like you want a keyboard hook. This looks like a good article.
It depends on what you are trying to do:
If you have a gui application and you want to handle key events then you can do that in a keydown eventhandler
If you want to do more low-level stuff and have an application that will intercept all key strokes (regardless of whether or not the application has focus/is visible) then you need to use pinvoke to hit the win32 apis. I suggest you read the following:
link text
Please let us know what you are trying to do so we can provide better feedback.
Using Google, I found this Keyhook example.
I've worked with keyhooks before, in Delphi WIN32, so I am a bit familiar with them. (Just not in C#.) If you add one to a DLL, all Hell might break loose since most virus scanners will recognise this as malware behaviour. (Especially if you use them in the wrong way, causing them to be injected in each and every process that's running on your system.)
A keyhook will allow key combinations to be captured from other processes, though.
For a solution without programming requirements: Drop a shortcut for the application on your desktop. Edit it, assign a shortcut, close it. Press shortcut to test...