I am currently working on a project where I need to control 16 pumps 1 stepper motor and 2 Distance sensors - 21 digital pins and 2 analog pins. I need to make a UI and have this use UI send information to the Arduino which will control my system. I would only need to receive 1 or 0 from each button press from the UI in order to determine which pump to needs to be turned on. I'm using an Arduino mega 2560 and coding the UI in Visual Studio C#.
I have done various research on serial communication for the Arduino, including using the serialevent() function and the firmata library. However I am having trouble understanding how all this ties together and if what I am wanting to do is even possible! Here are my questions:
Is this possible?
Is this possible by using Serialevent1()........... serialevent21()? or using Serial.availble() and Serial.read()
Instead of reading one button click on the UI at a time. Can the inputs on the UI be collected and sent to the arduino as a group. Then have the UI restart and clear out the values.
Any information and/or advice will help! I just need to be pointed in the correct direction!
Thanks
DG
Have you considered the following article?
It uses a Arduino mega 2560 and the article provides both the c# code and the Arduino code.
It communicates over the serial port and sends data in both directions.
Yes it is
The article above uses the Serial.print and readSerialInputCommand which is similar to Serial.read. You can use Serial.Read instead if you wish as it performs the same task and returns a different datatype.
You can compile the values into a group. If you want to be super optimized you can use bit-wise operators and compile the first 21 pin values into a byte array and send it.
However since its only 21 digital pins I recommend just using a string with the each character in the string linked to a pin. Eg: "10110" could set pin0, pin2, pin3 HIGH and set pin1, pin5 LOW.
I would recommend not restarting your UI as it will need to reconnect to serial port. Rather just clear all the values with your code.
Related
I need to write an application that can seat in the middle of a serial port communication between an application (3rd party, no source) running on my pc and a serial device connected to it (say on COM1).
The application normally communicates with the device as soon as you plug the cable. What I need to do is break this communication by "installing" my app in the middle so I can control what data goes through.
The only way I can think of solving this is creating a a pair of virtual serial ports (COM5<->COM6) using com0com. Then I would redirect the app to use COM5 instead of COM1 (I can set this in the app options) and then write a program that will copy every byte received in COM6 (sent by the application) into COM1 (sent to the device) and viceversa.
The problem is that I need to do this without introducing any delays into the communication, otherwise the application and the device will go out of sync.
I tried creating a C# console app to do this, but it seems to wait for a pause in the stream before raising the datareceived event, effectively introducing several ms of delay (speed is 9600).
What I would like to try now is to rewrite the program (maybe using the win32 api?) in such a way that it relays each rx byte as soon as it arrives, so the device would not notice any delay.
Can I do this using win32? Is there a simpler solution you can recommend?
Thanks
Maybe not much of a complete answer for your question but I think this might be worth a try.
Depending on your needs (you did not explain them) you can try to use Termite together with com0com. You can see a quick example here.
There is also an open source clone but I think the very feature you need (forwarding) was never implemented.
In any case, Termite allows scripting, so it is quite likely to be able to meet your needs.
I am working on a C# development project which aims at controlling a flying robot thanks to a set of Optitrack cameras (infrared Motion capture system). The concept works really well, you get a position from the camera system, our application can access to these data and we can control the robot.
The problem comes, I believe, from the communication chain. We have a USB cable linking our PC to an STM32F4 based board, which acts as a bridge and simply sends everything received on USB to radio thanks to an embedded NRF module (nRF24L01+ chip). This mechanic goes both way (NRF -> USB -> PC). The board is running under C using FreeRTOS. The PC runs Windows 10.
On the PC side we use the official STM32 VCP driver 1.4 from ST. On the board firmware, we have this user-made library for VCP on STM32F4: https://stm32f4-discovery.net/2014/08/library-24-virtual-com-port-vcp-stm32f4xx/
There are no queues on the bridge board except the ones from the radio module itself and potentially the STM32 VCP driver itself. I checked, there is a circular buffer in this driver used for in and out messages. Using JSCOPE I can visualize in real time how this circular buffer behaves and I've never seen an overflow happening.
My problem comes from the fact that a delay suddenly appears.
The system works perfectly for tens of minutes (between 10 to 20 minutes) and then a delay is clearly perceptible, which makes the controller oscillate. This happens when I do a second flight.
The following have been tried:
- Restart the C# application
- Run the C# application in debug mode and stand alone mode
- Change USB cable (shorter)
- Change USB port
- Change of computer
- Reinstall the ST VCP drivers
- Lower drastically the communication frequency (the control loop)
When the problem appears, the above solutions didn't work, the delay remains completely and none of the above proved to make it more reliable.
On the C# application, I reset all communication Lists before each flight. The SerialPort port object (from System.IO) has its buffers reset as well (DiscardOutBuffer, DiscardInBuffer, BaseStream.Flush methods)
I found a "hack" to make it work, but it is not what we want as a final solution. The "hack" is to simply physically disconnect / reconnect the USB connecting the board acting as a bridge. After this manipulation, the delay disappears.
So my questions are:
What could possibly bring this delay, knowing it doesn't look to be application dependant, nor frequency related (bandwidth).
What could explain why this disappear when unplugging/plugging the bridge board ?
I know this question is about a big project and could be hard to understand from outside. Feel free to ask me for more details if needed.
Cheers,
Marc
I've been trying to get CellIDs for multiple cellular towers to triangulate the position of a windows mobile phone in a C# application.
I am able to get the lat/long of the currently connected cell tower using David Tiger's WMLocationInfo dll from http://forum.xda-developers.com/showthread.php?t=934948, but this is not accurate enough because it uses only the current cell tower. I need an accuracy of ~100M or so without using GPS. So if I can get the CellIDs and signal strengths of at least three towers, I'll should be able to improve the accuracy to a reasonable extent.
I found a discussion at Get Multiple Cell IDs for location using Cellular Towers C# Windows Mobile where johansebasb was addressing the same requirement.
Can someone point me towards a sample project or code that I can use for this?
Thanks in advance.
There are two probs with that:
The RIL does not expose that function
You may send AT^moni command to GSM modem but this may disturb or corrupt the RIL. The RIL is sending and parsing all commands to control the modem. Think of the RIL being the wrapper around all modem communication.
You need a comm port to send (inject) AT commands to the modem. That may be implemented or not by the RIL driver.
If the modem does not support AT^moni you are lost. The Siemens MC75 supports cell monitoring via:
AT^SMONC Cell Monitoring
The AT^SMONC execute command delivers cell information containing 9 values from a maximum of 7 base stations. The first base station is the serving cell.
AFAIK Sierra Modems do support AT^moni too. Qualcomm? Don't know.
The Problem:
I'm writing an application that needs to receive electrical input from a machine every time the machine does something.
I have a Limit switch set up to the machine and it currently completes a circuit every time the machine does it's thing
I need it to input into a computer using usb as oppose to just complete a circuit.
I had a dataq 'dl-148u-sp' And i got the c# code to produce a graph using ActiveX controls but all i really need is the digital output from the circuit being completed (which for the life of me i couldn't figure out how to do)..
I ended up frying the device(i think) even the software it came with doesn't recognize it anymore...
I need a new device, and it turns out they discontinued the one i had, and the next one up after shipping is like 90$.
The Question:
Is there a Better/Cheaper/Easier way of doing this? Or can anyone suggest a Good device that's easy to get the output using c# code so i can incorporate it into a program i made?
It's not clear if you are asking for a hardware or software solution here. Are you asking what the best way to facilitate that data transfer from your machine to the PC? If so, this may not be the place to ask, but you might look at a USB to GPIO module.
http://numato.com/8-channel-usb-gpio-module is an example.
I'd recommend an Arduino:
http://www.arduino.cc/playground/Main/InterfacingWithHardware
They dev kits are cheap and there's a ton of open/free libraries that interface the Arduino to C#.
More expensive and complex board is IOFirebug with c# library and many functions. Input voltage range is from 5V to 30V.
I have an Arduino mega communicating over Bluetooth (bluesmirf gold device) to a C# application that I wrote. The Arduino is constantly sending a serial signal of 32 characters, the first always being an "S" and the last an "E". Using putty I can confirm that this signal is being sent correctly 99% of the time.
Now I want to read this signal with my C# application, which I am doing with the following code:
public string receiveCommandHC()
{
string messageHC = "";
if (serialHC.IsOpen)
{
while (serialHC.ReadChar() != 'S')
{
}
messageHC = serialHC.ReadTo("E");
serialHC.DiscardInBuffer();
}
return messageHC;
}
serialHC is of the serial class.
Sometimes this works perfectly but other times I'm having problems, I cannot find out why it works sometimes but others not.
The problem that I seem to be having is that sometimes I get a rather large Lag in the data that I am reading from the arduino. I notice this because I am sending button states and they only change a few seconds after I actually press or release the button on the Arduino. I used the standard baud rate of the Bluetooth device, which is 115200, and was wondering if changing that to a much lower rate could yield better results? What if any advantage would that have? I do not need hight communication rates, even updating the state 4-5 times a second would be acceptable for my application.
Is it possible the lag is coming from my code? I think it may be from the while loop that is waiting for the incoming "S" but then I don't see why it should hang there since there are new signals always coming in at a high rate.
I'm using the DiscardInBuffer() because I do not care about outdated data and just want to skip over that. It is much more important that I am reading current up to date data and acting on that fresh data.
Thank you for your help!
Best regards,
Bender
Update:
Just found out a bit more information while debugging. The problem only seems to appear:
When connected over Bluetooth (over USB cable there is absolutely NO Lag)
When a second Bluetooth connection is established from the PC to another device (different COM port and different baud rate)
Does anybody have any experience running two different devices off the same Bluetooth dongle on the PC? I can manage to connect to both no problem but still having the lag issue mentioned before.
Thanks for any help
You are not really using a physical serial port here. The BlueTooth driver merely emulates one. This is common, the Windows API has a well defined set of api functions to talk to a serial port. Emulating one makes the interface to the driver simple, the vendor doesn't have to supply an interface DLL or document a complicated DeviceIoControl() protocol.
Which means for one thing that the actual communication settings don't matter. Baudrate is meaningless in this scenario, it is the BlueTooth radio signaling that sets the transfer rate. The driver will accept whatever you select but will otherwise ignore it. Handshake signals might be interpreted, it's up to the driver to implement them. Communication error reporting is very rarely implemented, BlueTooth has an error correcting protocol, unlike a real serial port.
No, the loss of data here is entirely self induced. Clearly the driver does implement DiscardInBuffer(). Which accomplishes nothing but throw away any data that the driver received. This goes wrong if your code runs a bit late or gets interrupted by a thread context switch.
Delete the DiscardInBuffer() call.