is it possible to use spark core wireless to connect with pc via serial
because my codes was used for arduino connected via serial.
i wish to be using wireless for spark.
because i am using C# program that is not program by me, i was thinking that is it possible to treat a wifi connection as a serial connection
i could change the program for c# but it’s best to do little changes for that as i am not the one who program it therefor i have a hard time understanding that program
but i trying to understand how the UDP and TCP works for now
As dumb as it is, have you looked into a TCP-Serial Bridge? I’ve never needed to do so but I understand it can be done. Once bridged you should be able to use TCPServer or TCPClient (whichever you need depending on the bridge software
O.o what does it do?
i dont quite understand it
The Serial-TCP program bridges your existing Serial COM port and TCP/IP without the need for changing existing protocol. It works seemlessly and transparently, just like a pair of passive RS-232/RS-485/RS-422 repeaters, while the difference is that one requires installation of cables and converters with limited distance; and the other simply makes use of the existing computers and networks and a transmission distance that has no limit.
It essentially passes all serial information over a TCP socket. I would test it with something over than a Spark Core so you can get the hang of it. Perhaps you could whip up a TCPServer in node and point the TCP-Serial bridge to that? That way when you send serial commands using your C# program you could easily see the output to make sure everything is working correctly.
Maybe there is somebody local to you at a Makerspace or University that could help you with an overview of TCP communications. I could recommend some books but they are all very technical and might be more than you really need.
@harrisonhjones is suggesting that debugging something that talks to your existing C# program would be easier if you start with a program on PC rather than on a Spark core. This is smart advice since it would be a lot easier to debug and get working. But until you know a bit more about network communication, I think it will be hard for you.
not sure what your talking about but yes my c# is runing my my pc and i need to control my spark with my c# on my pc.
the program does this.
when button
pc-> timer starts
spark core -> press D0 change from low to high
spark core -> senor trips (trigger) serial reads it when value change D0 change to low
pc -> timer stops
it's something like a racing program.
but how do i even make the pc/spark core sent info over eachother using that tcp-serial
from what i seen both side have to be runing the program for it to be able to work?
Since you want to use WiFi instead of cable bound serial, you have to use the “WiFi language” (protocol) which is TCP/UDP rather than a “cable language”.
The TCP-Serial-Bridge is like an interpreter who speaks both languages and can translate in a (sort of) transparent (for either side concealed) way, so that each side can speak their native tongue and will only hear their native tongue.
Since you’d have three parties taking part on this conversation there will be starting troubles, especially since TCP/UDP seems to be new land for you.
So what @bko and @harrisonhjones suggest is to keep the setup as simple as possible, by at least staying in the same room (on only one machine or platform - not involving the Core already) to get the interaction C# program <–> bridge (maybe loopback IP) <–> simplest thinkable test program (e.g. echo) up and running.
Once you got this set up you can move on and talk across platform boundaries, starting with a simple Core sketch that only mimics your test program, before going deeper into the Core functionality.
I hope this has cleared thing up a bit more.
BTW: Your outlined use case could be resolved a lot easier if you had the possibility to rework your C# code - either by use of the Spark cloud or by avoiding the need for an interpreting bridge.
If you “virtualize” (abstract communication class and two implementations, one for serial and one for OTA) the “language” could be easily chosen e.g. via some property settings and the program could run against a serial device and the Core, just the same.