Re---Hoperf modules
- Thread starter centrex
- Start date
So only one way simplex? Try setups such as those shown => www.picaxe.orconhosting.net.nz Stan
Which little fellows do you mean? 433 MHz data transmitters and receiver modules have long been available via electronics outlets- in the US I recall RENTRON stock them => http://www.rentron.com/rf_remote_control.htm
The recent ( & superior) 2nd generation transceivers however are mainly only available ex. China or specialist Western stockists. The Sure Electronics offerings noted on EBay may be worthwhile- these are not ones I've used. But I strongly recommend starting simply with 433 MHz data, as numerous issues may arise- the least of which may be local interference. Stan
EXTRA: SbScott - if you mean HopeRF, then an order from MicroZed in Australia may be viable. They charge Aust $45 a pair (~US$30), but ex works in China they're well under ~half this price, although this is IN BULK & their p&p can be significant (as they courier everything).
The recent ( & superior) 2nd generation transceivers however are mainly only available ex. China or specialist Western stockists. The Sure Electronics offerings noted on EBay may be worthwhile- these are not ones I've used. But I strongly recommend starting simply with 433 MHz data, as numerous issues may arise- the least of which may be local interference. Stan
EXTRA: SbScott - if you mean HopeRF, then an order from MicroZed in Australia may be viable. They charge Aust $45 a pair (~US$30), but ex works in China they're well under ~half this price, although this is IN BULK & their p&p can be significant (as they courier everything).
Last edited:
Re the Sure ones, they are $36US per pair with free shipping and I think microzed is selling the Hope ones for $45AU per pair but I don't know what shipping is. It might end up very close in cost when you work out exchange rates etc.
I'm having to use the Yishi ones as they are the only module around with a big enough data buffer. Price is comparable with the Sure and Hope ones.
I'm having to use the Yishi ones as they are the only module around with a big enough data buffer. Price is comparable with the Sure and Hope ones.
lbenson
Senior Member
sbscott--in the U.S., Sparkfun have the 315 & 433mHz units--I've successfully used the 315s but failed with the 433s because of interference. I've also had success with the e-madeinchn TM1000-1 transmitters ($2.50+$4 shipping for as many as you get) -- http://stores.ebay.com/e-MadeinCHN_W0QQcolZ4QQdirZ1QQfsubZ0QQftidZ2QQpZ2QQsclZ1QQtZkm -- sending to the Sparkfun receiver. Didn't get it working with the e-Madeinchn receiver, but need to revisit now that I have known-good circuits.
Stuck on COM1?? Here's the fix!
Hi People,
Regarding the COM1 issue, if you download VSPE you can re-direct the COM port to any other real port number. This software can do several other 'virtual' things also, as well as COM-UDP re-direction.
BEST of all, it is FREE to use forever.
Only limitation is that you can only use one setup at a time.
But you can set up different profiles to start from a shortcut on the desktop.
I am using it to set up a 'virtual' com port pair. One software, AISMon, sends out over one (Com8), and NavMonPC reads on the other (Com9).
Very easy to use.
Only for 32 bit Windows systems!
Hope this helps somebody out.
Hi People,
Regarding the COM1 issue, if you download VSPE you can re-direct the COM port to any other real port number. This software can do several other 'virtual' things also, as well as COM-UDP re-direction.
BEST of all, it is FREE to use forever.
Only limitation is that you can only use one setup at a time.
But you can set up different profiles to start from a shortcut on the desktop.
I am using it to set up a 'virtual' com port pair. One software, AISMon, sends out over one (Com8), and NavMonPC reads on the other (Com9).
Very easy to use.
Only for 32 bit Windows systems!
Hope this helps somebody out.
PICAXE + HOPERF + ROCKETS .... hehe!!
Alright, I had to do it and I even built in a safety system.
The rock is not controlled by PICAXE nor is it controlled by Hamas and its not aimed anywhere it shouldn't be.
I thought it would be interesting to modify a model rocket launcher we use, from wired to wireless.
The launcher has elevation and rotational adjustments and up to 4 rockets can be loaded for launch at once.
NOTE these rockets only used A type motors (estes) and have max elevation of about 75 - 100 metres max. So they would be lucky to carry a firecracker and get over a fence, let alone the border.
We used to have a 50 metre length of 7 core trailer wire going from the launcher to the control box.
We now have only 2 wires going from the launcher to the control box.
These will make so readers happy, they are in the final ignition circuit and if the hand held switch is not ON then the ignition battery is isolated and no launch can occur.
The elevation, rotation and alarm systems are activated wirelessly and will function with or without the firing circuit engaged.
If the firing ciruit is active then the wireless unit can fire the rockets, a little pinch of safety added for safety, to be safe.
By the way this device is not mounted in a vehicle and is not powered be the same
Alright, I had to do it and I even built in a safety system.
The rock is not controlled by PICAXE nor is it controlled by Hamas and its not aimed anywhere it shouldn't be.
I thought it would be interesting to modify a model rocket launcher we use, from wired to wireless.
The launcher has elevation and rotational adjustments and up to 4 rockets can be loaded for launch at once.
NOTE these rockets only used A type motors (estes) and have max elevation of about 75 - 100 metres max. So they would be lucky to carry a firecracker and get over a fence, let alone the border.
We used to have a 50 metre length of 7 core trailer wire going from the launcher to the control box.
We now have only 2 wires going from the launcher to the control box.
These will make so readers happy, they are in the final ignition circuit and if the hand held switch is not ON then the ignition battery is isolated and no launch can occur.
The elevation, rotation and alarm systems are activated wirelessly and will function with or without the firing circuit engaged.
If the firing ciruit is active then the wireless unit can fire the rockets, a little pinch of safety added for safety, to be safe.
By the way this device is not mounted in a vehicle and is not powered be the same
geaniepenguin
New Member
Grant Fleming
Senior Member
Welcome to the forum.
Haven't used it yet on my HOPE devices but it certainly will give a lot more flexibility especially for us PICAXErs who usually have all manner of experiments tied up with with specific com ports (com 1 being always taken).
Nice find!
Haven't used it yet on my HOPE devices but it certainly will give a lot more flexibility especially for us PICAXErs who usually have all manner of experiments tied up with with specific com ports (com 1 being always taken).
smithy2167
New Member
Yishi Module
I'm late to this thread, but some good info in here.
I've been setting up a remote monitor for a solar inverter using Hope HM-TR modules as a transparent RS-232 link. I was hoping (!) to get away without a processor. However, the inverter status message is 91 bytes long and only 63 bytes are getting through the link. The current Hope data sheet makes no mention of the 32 byte buffering limit which I've now read about in this thread.
So my current options seem to be:
- add something like an 08M to provide buffering (bit messy)
- try to hunt down the firmware for the ATMega48 on the Hope board, tweak it for a larger buffer size (there's 512 bytes of RAM) and re-burn (very messy!)
- go to another module like the Yishi also mentioned here.
Option 3 seems the best, but info on the Yishi site is fairly sparse.
So, I wonder if someone (Dr Acula?) could please provide a summary of their findings with the Yishi's. Also, the CS10U vs. CS20U (as they are now called). Is there a local source and, finally, cost.
Thanks,
Dave.
I'm late to this thread, but some good info in here.
I've been setting up a remote monitor for a solar inverter using Hope HM-TR modules as a transparent RS-232 link. I was hoping (!) to get away without a processor. However, the inverter status message is 91 bytes long and only 63 bytes are getting through the link. The current Hope data sheet makes no mention of the 32 byte buffering limit which I've now read about in this thread.
So my current options seem to be:
- add something like an 08M to provide buffering (bit messy)
- try to hunt down the firmware for the ATMega48 on the Hope board, tweak it for a larger buffer size (there's 512 bytes of RAM) and re-burn (very messy!)
- go to another module like the Yishi also mentioned here.
Option 3 seems the best, but info on the Yishi site is fairly sparse.
So, I wonder if someone (Dr Acula?) could please provide a summary of their findings with the Yishi's. Also, the CS10U vs. CS20U (as they are now called). Is there a local source and, finally, cost.
Thanks,
Dave.
Yishi work in an almost identical fashion to Hope. Yishi have a 256 byte buffer, and as far as I know, are the only ones with this size. Probably easier to use than Hope as there is no setup needed. You tell them in advance which baud rate you want. Data in=data out, just like a 3 wire RS232 connection. Cost was about the same as Hope (ie roughly $25ea), plus shipping (which was as expected for the weight). No local suppliers. The biggest hassle was the payment as they don't do paypal, but I discovered a web page in my bank account that does international bank to bank transfers, and it was just a few mouseclicks in the end and cost about the same as paypal.
Go for the YSC20U. 10mW, ultra sensitive Rx (-121dB). (I still haven't fully debugged the 500mW YSC20L modules, the RF tends to come back down the data and power wires and I think the only solution is a metal box with ferrites on the wires as they go into the box, plus or minus a ferrite bump like the ones on VGA monitor cables). This is not an issue under 100mW and certainly not at 10mW.
Let me know if I left anything out!
Go for the YSC20U. 10mW, ultra sensitive Rx (-121dB). (I still haven't fully debugged the 500mW YSC20L modules, the RF tends to come back down the data and power wires and I think the only solution is a metal box with ferrites on the wires as they go into the box, plus or minus a ferrite bump like the ones on VGA monitor cables). This is not an issue under 100mW and certainly not at 10mW.
Let me know if I left anything out!
I too have had very positive experiences with those Yishi, & in retrospect may well have promoted them (instead of HopeRF's offerings) if they'd turned up earlier. NB: In most parts of the world the 433 MHz ISM band is limited to 25mW transmitter power, so those higher power Yishi's Dr_A mentions are strictly illegal. The best a skinflint user can do is thus go for a superior receiver. There are many other individual 433 MHz transmitter & receivermodules around- Jaycar's "Keymark" etc.
smithy2167
New Member
Thanks for the info.
I contacted Yishi and got a rather rambling reply. However, the essence was that the C10U is $US17, C20U is $US23 and shipping by DHL is $US18. Payment methods are only T/T or Western Union. The T/T incurs an additional $US25 "Bank Transition" fee from them (as well as the $A22 my bank would charge me). So, much as I dislike using W/U for such things, it seems to be the choice and I don't think they are trying to scam me.
So, looks like the C10U is the choice. If anyone is interested in getting some, please contact me in the next few days and I can add them to the order and we can share the costs.
I contacted Yishi and got a rather rambling reply. However, the essence was that the C10U is $US17, C20U is $US23 and shipping by DHL is $US18. Payment methods are only T/T or Western Union. The T/T incurs an additional $US25 "Bank Transition" fee from them (as well as the $A22 my bank would charge me). So, much as I dislike using W/U for such things, it seems to be the choice and I don't think they are trying to scam me.
So, looks like the C10U is the choice. If anyone is interested in getting some, please contact me in the next few days and I can add them to the order and we can share the costs.
smithy2167
New Member
Forgot to say, if modules like the Hope have these buffering issues, why don't they implement data flow control? RTS/CTS handshaking has been around as long as RS-232. If they don't want to add another pin, what about software handshaking (although this wouldn't work in my case, with binary data)?
Maybe I should look for Hope's suggestion box ;-)
Maybe I should look for Hope's suggestion box ;-)
W/U probably is the answer then. Whereabouts are you, Smithy?
Doing joint orders is also a good idea - my joint order was $900 in total so the bank fee was a small percentage in the end.
Re buffering, as far as I know, nobody implements a true RS232 connection with handshaking, ie RTS/CTS. It would be another layer in the RF background, and I guess with spread spectrum and other fancy systems it could work. Straight analog can't do multiple channels and neither can FSK (which I think is what the Yishi modules use).
There are all sorts of variants with RS232. RTS/CTS is one. Then there is implementation of the 'break' signal, which I don't think RF modules do either. Though if anyone ever did, it would mean you could program a picaxe wirelessly.
Doing joint orders is also a good idea - my joint order was $900 in total so the bank fee was a small percentage in the end.
Re buffering, as far as I know, nobody implements a true RS232 connection with handshaking, ie RTS/CTS. It would be another layer in the RF background, and I guess with spread spectrum and other fancy systems it could work. Straight analog can't do multiple channels and neither can FSK (which I think is what the Yishi modules use).
There are all sorts of variants with RS232. RTS/CTS is one. Then there is implementation of the 'break' signal, which I don't think RF modules do either. Though if anyone ever did, it would mean you could program a picaxe wirelessly.
Smithy: Indeed - just where are you!? I may be interested in a shared order too, but I'm getting out of synch. with Yishi's product coding. Are these offerings new models or just revamps? My jottings indicate their YS-1020U was the preferred module earlier this year. This C10U offers a high data rate, but it's receiver is nothing special. Mmm -the C20U may be the culprit, as it looks identical to my YS-1020U. Any insights?
smithy2167
New Member
I'm in Melbourne (Australia!).
Sorry, some finger trouble here causing slight confusion. I was looking at both the YS-C20U (was YS-1020U) and the 50mW YS-C10U (was YS-1100U). I meant to say that the lower (legal) power one - C20U - was the one I was interested in. However, any order could include a mix of modules if required.
In the confusing Yishi email, there were supposed to be data sheets for both of those modules attached, but they didn't make it through. I've asked them to re-send.
Sorry, some finger trouble here causing slight confusion. I was looking at both the YS-C20U (was YS-1020U) and the 50mW YS-C10U (was YS-1100U). I meant to say that the lower (legal) power one - C20U - was the one I was interested in. However, any order could include a mix of modules if required.
In the confusing Yishi email, there were supposed to be data sheets for both of those modules attached, but they didn't make it through. I've asked them to re-send.
smithy2167
New Member
Yes, a full end-to-end handshake would be a major challenge on a half duplex link. However, I was only thinking of a local handshake. I get the impression that the problem is between the data source and the Hope module - it's puny 32 byte buffer fills and it can't then simultaneously transmit the data and continue to take in data from the source, even at a lowly 1200 baud. If the Hope had a simple "hang on a sec - buffer is full" flag, then the source could pause until the Hope was ready again.
We can only dream ...
hippy
Ex-Staff (retired)
The problem with RF transmitter modules is that they are ultimately designed to be cheap and cheerful, at the basic level just an oscillator which can be turned on and off which generates a radio signal or not. The price one pays for low cost is put on the end user who has to do everything to control the module and work round its limitations.
As buffering, hand shaking and whatevery else gets added to make the end-user's life easier the cost of the modules rise because of component and R&D costs.
With commercial customers looking primarily at component costs ( their R&D costs being minimal compared to costs saved on large manufacturing runs ), it's hard to create a compelling product which gets them to pay the money and move in-house development costs over to compnent costs. More advanced, more easily usable modules, tend to therefore end up as more niche markets and don't have the economics of scale which brings their price down.
Move enough into a module and the balance can be shifted. The price of a complete module and what it does outweighs the in-house R&D.
What's really being asked for is XBee for 433MHz rather than for ZigBee, and at low cost.
Whether that will ever happen really depends on whether a manufacturer sees there's a large enough market to justify it. For those who want that, it can all be concocted using cheap microcontrollers, so manufacturers may see no advantage or market for doing it themselves.
Local CTS/RTS handshaking could probably be achieved by putting a PICAXE between the master and transmitter and it would increase the buffer size as well. It may well be possible to use cheaper, dumber TX modules as functionality moves into the intermediate PICAXE.
Whether people are prepared to do that, or pay the cost for it, is a different matter. Until a manufacturer does add it themselves the options seems to be not have it, pay the cost of working around what you have to work with, or move to a different technology which does provide what's wanted.
As buffering, hand shaking and whatevery else gets added to make the end-user's life easier the cost of the modules rise because of component and R&D costs.
With commercial customers looking primarily at component costs ( their R&D costs being minimal compared to costs saved on large manufacturing runs ), it's hard to create a compelling product which gets them to pay the money and move in-house development costs over to compnent costs. More advanced, more easily usable modules, tend to therefore end up as more niche markets and don't have the economics of scale which brings their price down.
Move enough into a module and the balance can be shifted. The price of a complete module and what it does outweighs the in-house R&D.
What's really being asked for is XBee for 433MHz rather than for ZigBee, and at low cost.
Whether that will ever happen really depends on whether a manufacturer sees there's a large enough market to justify it. For those who want that, it can all be concocted using cheap microcontrollers, so manufacturers may see no advantage or market for doing it themselves.
Local CTS/RTS handshaking could probably be achieved by putting a PICAXE between the master and transmitter and it would increase the buffer size as well. It may well be possible to use cheaper, dumber TX modules as functionality moves into the intermediate PICAXE.
Whether people are prepared to do that, or pay the cost for it, is a different matter. Until a manufacturer does add it themselves the options seems to be not have it, pay the cost of working around what you have to work with, or move to a different technology which does provide what's wanted.
smithy2167
New Member
Certainly, the "dumb" versions that simply switch the RF in time with the input data could not do any handshaking (nor should they need to).
However, the Hope modules already have an ATMega48 onboard. There's 512 bytes of RAM, 4K of program memory and there are sure to be spare I/O pins (perhaps the Config or Test pin could be put to double use as a Handshake output, avoiding any hardware changes). Thus production costs should remain the same. About the only need is for a firmware change, and I don't think that would be difficult.
Has anyone ever attempted to "get in" to the Hope ATMega to see if the protection bits are set? I notice that the SPI pins (PB3-5) come out to pads near the antenna socket. I'm almost tempted to try to mod the firmware, provided that the original firmware is accessible.
However, the Hope modules already have an ATMega48 onboard. There's 512 bytes of RAM, 4K of program memory and there are sure to be spare I/O pins (perhaps the Config or Test pin could be put to double use as a Handshake output, avoiding any hardware changes). Thus production costs should remain the same. About the only need is for a firmware change, and I don't think that would be difficult.
Has anyone ever attempted to "get in" to the Hope ATMega to see if the protection bits are set? I notice that the SPI pins (PB3-5) come out to pads near the antenna socket. I'm almost tempted to try to mod the firmware, provided that the original firmware is accessible.