|
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..
|
|
|
|
|
Faster than what?
What do you mean by 'greyscale'?
|
|
|
|
|
Member 8652316 wrote: I want the code
Don't ask for code. Ask for ideas instead.
|
|
|
|
|
I want Salma Hayek. We're both going to be disappointed tonight.
|
|
|
|
|
|
If I have several versions of the same DLL in the GAC which I always encounter.
When my application run, which version is selected to run if I did not specify which version of the dll to be used in the .net application.
Thanks.
|
|
|
|
|
When you specify a DLL in a project (web or windows) the version is also specified in there. I.E.:
<compilation>
<assemblies>
<add assembly="System.Data, Version=1.0.2411.0,
Culture=neutral,
PublicKeyToken=b77a5c561934e089"/>
</assemblies>
</compilation>
This is the version selected by your app.
"Whether you think you can, or you think you can't--either way, you are right." — Henry Ford
"When I waste my time, I only use the best, Code Project...don't leave home without it." — Slacker007
|
|
|
|
|
I don't think that answers the question. The question states, "if I did not specify which version"; what you show appears to specify the version.
I also notice that when I look at the properties of a reference (in VS) I can set Specific Version to true or false, I've always seen it as false, so which version will be used at run time?
Plus, as for me, I generally compile at the command line and don't use VS and its project files; so which version is used then?
|
|
|
|
|
I think it's the highest version which is compatible with the version of the .Net Framework you're compiling against.
|
|
|
|
|
You can of course actually get the version at run time. So you can run your app and then print it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
