|
shahrulnizam wrote: they can insert their data peacefully without needing to worry about other people data.
In your database table create a field for the user ID. Then set the BindingSource.Filter property to the current userID, so that the DataGridView displays only the records pertaining to the current user. While adding the new row, using DataGridView.RowsAdded event set the userID filed of the new row to the current userID
|
|
|
|
|
where to set the bindingSource.filter??it's not at the properties window..
|
|
|
|
|
|
Hi All,
I have done lot of java work for more than 8 years. But I am new to C#. I am writting a client to the Simple Application. For that Client I need to add header..
Here is the scenario...
Server SIde code is written in Java and exposed as Web service.
Client SIde is Written in .Net/C#. I need to access that webservice.. And I am sucessful. Now I need to add a header so I can pass *ID* 122344*/ID* through soap Header. Can some one suggest me , How to do that.. I have been strugulling on this for more than 3 days..Any help really appreciated.
|
|
|
|
|
If you derive a class from your web service reference, you can override the method GetWebRequest. At this point, you can add your own headers through the Request object.
|
|
|
|
|
Hi Folks,
Does anyone have a good starting point for information on reading RF signals using C#? I have an electric smoker (ie. BBQ Pit) that has an RF remote that displays different temperatures and I would like to write an application that would allow me to control the remote functions from my PC instead of from the remote.
I'm sure I would need to purchase an RF Receiver such as this one[^] which I will if I can figure out that this is possible!
|
|
|
|
|
I don't have a guide to point you at, but he first thing you need to find out is what frequency the transmitter on the smoke is using. Then you can make sure you get a RF transceiver that can handle it.
The next thing is determining if there is any protocol that is being used to transfer application-level data, if any.
After that, determine the format of the data coming from the smoker so you can get the correct temperature. Then what are the commands you send back to the smoker to do what and what is the format of those commands??
If you can't find documentation on any of this stuff, you're going to find it extremely difficult to do this from your code.
|
|
|
|
|
Thanks for the info Dave!
I search for the FCC ID on fcc.org and found a lot of information about the module and its communication methods. The handheld remote unit contains a 433 Mhz transceiver - is there something more specific than that I should try and find out related to the frequency, or should any 433 Mhz transceiver be able to communicate with it (depending on the protocol as you mentioned)?
As you said, I'm sure it will be extremely difficult to figure this out without any documentation - but I think if I can get a transceiver and get the communication going between the two then I can figure out the functions (again, there is a lot of info on the FCC site).
Do you know sort of what the process would be for communicating with the transmitter on the smoker would be? I guess I would ideally have a USB transceiver so once it was installed I guess you would just use the USB API to communicate with it as a HID, right? (I know that is oversimplifying what could be a painful process) Is there a process of "pairing" devices a la bluetooth or do these types of things work more off of just responding to any frequency that matches what it's looking for?
|
|
|
|
|
lydonbergin wrote: The handheld remote unit contains a 433 Mhz transceiver - is there something
more specific than that I should try and find out related to the frequency, or
should any 433 Mhz transceiver be able to communicate with it (depending on the
protocol as you mentioned)?
Not really. You just need to make sure the transceiver you get supports that range.
lydonbergin wrote: but I think if I can get a transceiver and get the communication going between
the two then I can figure out the functions
The problem with "figuring out the functions" is that they are application (software) specific, not radio specific. One possible method would be to try and listen to the remote to see what it's sending. You're probably going to get a bunch of bytes, but no idea what they mean.
lydonbergin wrote: Do you know sort of what the process would be for communicating with the
transmitter on the smoker would be? I guess I would ideally have a USB
transceiver so once it was installed I guess you would just use the USB API to
communicate with it as a HID, right?
Hehe. You are putting WAY too much thought into this part. Chances are really good that the transceiver will show up as a serial port on your PC. You don't need any USB garbage to talk to it. Just normal serial communications in the System.Io.Ports namespace.
lydonbergin wrote: (I know that is oversimplifying what could be a painful process) Is there a
process of "pairing" devices a la bluetooth or do these types of things work
more off of just responding to any frequency that matches what it's looking for?
Neither. You should just get data if there's anything coming over the air, no matter what the source is just so long as it's on a frequency the transceiver is listening to. There is no pairing or anything like that.
|
|
|
|
|
I can't thank you enough Dave - this information has been VERY informative.
|
|
|
|
|
Or, if you're adventurous enough and know some basic electronics, you can build your own system from scratch. Have a look at a Fez Panda[^] and the .NET Micro Framework.
|
|
|
|
|
If you want to control the BBQ you will need a transmitter not a receiver. A trasceiver if two way communication is required.
It may be easier to get a second remote and use your PCs parallel or serial port to control an interface to the keyswitches on the remote rather than trying to identify what code does what.
You will also need to watch your max permitted power and the risk of RF interference as that remote contol is not a Primary allocation for that part of the RF spectrum
|
|
|
|
|
greldak wrote: It may be easier to get a second remote and use your PCs parallel or serial port to control an interface to the keyswitches on the remote rather than trying to identify what code does what.
Do this. Seriously. That remote is the exact frequency radio with the exact kind of modulation you need, and already knows how to speak any and all protocols you'll need. Even if all you do is grab the radio guts from it, its probably the cheapest compatible radio you'll be able to find.
Even a simple start like keywitches will be a fun little project, is easily doable with C#, and, perhaps most importantly, you'll have something basic up and working in a few weeks. Then you can decide whether to have your fun writing control code, or climbing learning curves as you peel the onion of how the remote talks to the device.
For the keyswitch control itself, you could use either parallel port or USB (I'm thinking FTDI serial chip in bit bang mode) without too much difficulty. For USB, consider checking out smileymicros or sparkfun for a simple packaging of that FTDI chip.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
It's all about documentation.
Once, you found out the correct frequencies, you can buy the correct transceiver for your case. Usually RF transceivers suppliers have drivers and ready to go libraries to use them. So before you purchase one, contact the manufacturer or try to find in their website if they have documentation and libraries you can download.
Ideally you'd want ready to go .net libraries, but COM libraries would be just as easy, you just add it as reference to your project and VS will build a nice wrapper for you.
As a last resort you can P/Invoke[^] if the supplied libraries are of some other unmanaged kind.
Now, the hardest thing to do will be to talk to the smoker. There are two approaches:
1 - Contact the smoker manufacturer and ask them for documentation. Ask what commands the smoker expects and what output it produces.
2 - Reverse Engineering: In this case it's not so difficult if you just want to receive information, because you can observe what the smoker transmits while you mess with it and from there, deduce the results. Often this doesn't give much trouble, but that is not always true. The hardest would be to control the smoker, however, you could also observe the commands issued by the remote and reproduce them with your transmitter.
The second approach will take time and effort, however it is possible to do it.
As a first exercise you should get acquainted with the workings of the RF protocol. I find the best way to do it buy playing with it. All you'll need to do is some googling at first, then setup the transceiver on your pc and use the remote to get the first contacts.
But it is very important that you research the transceiver manufacturer and their support before you buy them, so it's the best fit for you.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
Fabio Franco wrote: 1 - Contact the smoker manufacturer and ask them for documentation. Ask what
commands the smoker expects and what output it produces.
Then sell them the resultant program you write.
|
|
|
|
|
GenJerDan wrote: Then sell them the resultant program you write.
So they can offer a premium package with the smoker when they sell it to restaurants, everybody wins.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
My experience has been that marketing/legal jumps in and claims the data is proprietary and cannot be given out. I suspect this is mostly because they do not have any documentation other than handwritten, coffee ringed, legal pads. The lawyers will not like it because that may expose them to liability issues should you make something that blows up either because their documentation was wrong or you interpreted it wrong. Sometimes after you get past all that, there will be someone who thinks you should pay them outrageous amounts of money for the privilege of seeing their crappy documentation/protocols.
YMMV
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
|
The easiest route might be to use the existing remote, although it will involve some hardware work. It already has a transceiver. You could tap in to the rx/tx signals which will be at logic levels (e.g. 0/3.3 volts). Or even the display and buttons...
|
|
|
|
|
Guys,
you have a really big challange ahead here. I know alot about RF, so here are the facts.
433mhz is pretty standard for this type of device. You will also see it used in things like remote temp sensors(oregon scientific) and such.
You can get some good inexpensive receivers from companies like Linx.
The bad news is these don't work like you imagine. the radios are very basic, just simple ASK(amplitutde shift keyers). This means there is NO protocol of any kind out of them, just a bit indicating energy was transmitted, this is called a data slicer.
To use them you need to bolt them up to an encoder or a microcontroller to generate a bit sequence. this could be something like an RS232 byte, but not usually the case. Most times these are manchester encoded bit streams, this to meet FCC specs and produce a reliable transmission. If you take the output and just hook it up to an RS232 level converter, you probably won't have much sucess even if you can decode the enoding scheme in the pc.
I suggest you open up the remote. Look at the chips in it. There will be either 1 of 2 methods. 1 is a microcontroller doing all the work and scanning the buttons(I'll bet not for this cheap a deal).
2. a holtec encoder chip doing the work, this is a very cheap solution. If you have this, then you can eliminate all the pain. You just need to tap the switch contacts with relays or fets and connect this back to the pc. A parallel port would work, or just soemthing like the RTDI rs232->parallel chips. They also make cables with these parts in them that could be made to work easily on the 3.3v levels(if that is what is in there...)
Good luck...
ken
|
|
|
|
|
Oh dear, I got all happy when I misread that as you wanting to read information from HF using C#, which is of course also RF, but most modern RF is UHF, and my arcane and atrophied knowledge of analogue HF radio magic remains dormant for another epoch.
|
|
|
|
|
I want the code to load an image and it must show that, it is color image(or) gray scale image.. in a faster way..
Thanks,
Sukesh
|
|
|
|
|
What's a gray scale image?
Gray is a color, so why not always report color? 
|
|
|
|
|
Member 8652316 wrote: in a faster way..
You will have to look at all the pixel colors, and it is not "fast".
One way to check if the image is grayscale, is if the RGB components of each pixel are equals to each other.
Red == Green == Blue.
M.
Watched code never compiles.
|
|
|
|
|
Thanks for your response i used this logic also.. but it is slow..
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
