pwm remote
- Thread starter Efried
- Start date
Efried
Active Member
rossw said:
rossw said:
thanks, with remote I mean wireless. The WC shall act as master and two fans are controlled via PWM over the air.
eventually zigbee components for LED control are usable
http://examples.digi.com/lights-motors-more/802-15-4-pwm-output-with-an-led/
the sender connected to the WC might be something like that http://www.jennic.com/
Efried
Active Member
After scanning some solutions like Zigbee and BLE I think the best one would be using a cheap small WC for the PWM fan control..,
since such device does not exist, an alternative would be this controlled by the WC:
http://www.aliexpress.com/item/New-HC-06-Wireless-Bluetooth-Serial-Backplane-RF-Transceiver-For-AVR-For-Arduino-RS232-Free-SHipping/32220231229.html
plus that receiver:
http://www.aliexpress.com/item/Bluetooth-pwm-dimming-module-mobile-phone-dimming-intelligent-dimming-smart-home/1941991700.html
However without some generic pairing support built into the WC this will not be an easy job to do.
Replacing X10 by BLE in the WC would be highly appreciated...
since such device does not exist, an alternative would be this controlled by the WC:
http://www.aliexpress.com/item/New-HC-06-Wireless-Bluetooth-Serial-Backplane-RF-Transceiver-For-AVR-For-Arduino-RS232-Free-SHipping/32220231229.html
plus that receiver:
http://www.aliexpress.com/item/Bluetooth-pwm-dimming-module-mobile-phone-dimming-intelligent-dimming-smart-home/1941991700.html
However without some generic pairing support built into the WC this will not be an easy job to do.
Replacing X10 by BLE in the WC would be highly appreciated...
CAI_Support
Senior Member
X10 does not use much RAM or EEPROM space, removed that will not save much code space or RAM. Bluetooth will take a lot of RAM and EPROM to implement. Remove X10 does not gain enough space to implement anything else.
We understand the needs for extending support to different devices, so that we added I2C and SPI support. You can have I2C eeprom to store your configuration data, and SPI supported wifi transmitter and receiver.
Please update your board with latest firmware, then you can experiment with I2C and SPI device support in PLC. That opens a wide door for devices support of any kinds. With I2C and SPI, anyone familiar with the kinds of devices you mentioned can write PLC code to support them. There are tons of devices based on I2C and SPI, and they are low cost, too.
We understand the needs for extending support to different devices, so that we added I2C and SPI support. You can have I2C eeprom to store your configuration data, and SPI supported wifi transmitter and receiver.
Please update your board with latest firmware, then you can experiment with I2C and SPI device support in PLC. That opens a wide door for devices support of any kinds. With I2C and SPI, anyone familiar with the kinds of devices you mentioned can write PLC code to support them. There are tons of devices based on I2C and SPI, and they are low cost, too.
Efried
Active Member
you are shifting workload to the users, but you may miss part of the market if there is no scalable but easy to set up ecotope. name it hats or extension or interface modules. I see not that much memory restrictions for implementing a tcp/ip stack using the wc32 architecture.
CAI_Support
Senior Member
It is not shifting to the users. If we did not allow PLC extension for different chips through I2C and PLC, then we had to release many different firmwares, If user wanted to have two features in two different firmware, then it would not work. By allowing use it on the I2C and SPI bus, one firmware will handle them all.
I2C and SPI support provide an elegant way to support wide variety of devices through easy PLC programming. You have to try it to understand the beauty of this.
Even with WC32, special protocol will require certain IO pins to be dedicated for certain function only. That is too limiting. What is the point that function can work fine with I2C and SPI for less but insisted on reducing general IO and cost more for the same result?
I2C and SPI support provide an elegant way to support wide variety of devices through easy PLC programming. You have to try it to understand the beauty of this.
Even with WC32, special protocol will require certain IO pins to be dedicated for certain function only. That is too limiting. What is the point that function can work fine with I2C and SPI for less but insisted on reducing general IO and cost more for the same result?
Efried
Active Member
CAI_Support said:
I think you don't attribute enough thoughts differentiating between customer development on a client side and such on the master side. If you have a WC32 as master, communicating via SPI to a BLE module, every user would profit from BLE functionality,
may be it's only a day or so for a coder
http://dmitry.gr/index.php?r=05.Projects&proj=15&proj=11.%20Bluetooth%20LE%20fakery
http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=41939
http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf
please help
thanks
CAI_Support
Senior Member
Efried,
You probably did not read the URL you posted in detail, or you did not bother to read chip specs.
We had done the careful study and talked to the support engineers in the chip manufacture a year ago, when we started working on I2C and SPI protocol.
Those chips you mentioned do wifi or Bluetooth protocol over the air. Their hardware protocol is I2C. That is one reason that we added support for I2C.
To write software to use those chips, you first decide hardware protocol, then configuration of the wifi or Bluetooth, then upper layer your own user data and communication protocol on top the wifi or Bluetooth.
Those chip provided wifi or Bluetooth layer, WebControl provided SPI hardware layer and PLC command for your to send anything to those chips. It is user's responsibility to decide what you going to send MAC address of your own, how do you let both sides of the wifi or Bluetooth understand what they talked about.
Are you expect we would apply MAC address range for you through IEEE, and determine what the data going to send back and forth over wifi and Bluetooth? IEEE charge for the MAC address assignment. If you just use any you like, nobody probably cares about it. If we apply for you, they will charge $1000 for each block of MAC address for you.
There was a thread about this wifi chip we posted here, we asked anyone had any interest to use them, and willing to help users to work on PLC code. If you really wanted to work on that, you could post into that thread of discussion, instead of keep writing into PWM thread. In that way, other users can follow and read easily. That is a rule for most discussion forum.
You probably did not read the URL you posted in detail, or you did not bother to read chip specs.
We had done the careful study and talked to the support engineers in the chip manufacture a year ago, when we started working on I2C and SPI protocol.
Those chips you mentioned do wifi or Bluetooth protocol over the air. Their hardware protocol is I2C. That is one reason that we added support for I2C.
To write software to use those chips, you first decide hardware protocol, then configuration of the wifi or Bluetooth, then upper layer your own user data and communication protocol on top the wifi or Bluetooth.
Those chip provided wifi or Bluetooth layer, WebControl provided SPI hardware layer and PLC command for your to send anything to those chips. It is user's responsibility to decide what you going to send MAC address of your own, how do you let both sides of the wifi or Bluetooth understand what they talked about.
Are you expect we would apply MAC address range for you through IEEE, and determine what the data going to send back and forth over wifi and Bluetooth? IEEE charge for the MAC address assignment. If you just use any you like, nobody probably cares about it. If we apply for you, they will charge $1000 for each block of MAC address for you.
There was a thread about this wifi chip we posted here, we asked anyone had any interest to use them, and willing to help users to work on PLC code. If you really wanted to work on that, you could post into that thread of discussion, instead of keep writing into PWM thread. In that way, other users can follow and read easily. That is a rule for most discussion forum.
Efried
Active Member
CAI_Support said:
I started this thread because I need PWM and see that there is a lot of BLE devices using PWM for LED control. Thanks anyhow for explaining why BLE is no solution. I'm not sure if you studied the abbreviated version using advertising only (I already posted that in the other thread)
http://www.eetasia.com/ART_8800686229_499488_TA_674c51a7.HTM
CAI_Support
Senior Member
I think you don't really understand how the hardware working in the lower layer. WC8 and WC32 are already provided solution to use any I2C and SPI bus based sensors and IO devices. Using PLC commands to send configuration to the chips and communicate with them are easy and fun to do.
CAI_Support
Senior Member
If you really want a PWM output, you can purchase this interface board with WC8 or WC32, it can control a lot of PWM outs!
Code:
http://www.ebay.com/itm/251704156566Efried said:
We've not actually had any "specification" of what you want to do.
You've complained that CAI are not doing enough, not doing what you want, not doing it the way you would do it, that primative I2C/SPI isn't "good enough", etc etc, but nowhere that I've seen have you given us any indication of your actual needs.
"wireless remote" to me means "anywhere in the world" - over the internet and a last-mile of 802.11(whatever) to the controller.
Clearly YOUR interpretation is different.
How many channel? What distance? Frequency limitations? OTA encryption or security? Multidrop? What power are you wanting to control? What voltage? Continuous PWM or only for short periods? Etc etc etc.
Don't blame others for not telling you what you want to hear when you don't clearly identify what the task is!
Efried
Active Member
rossw said:
Ok, may be that will give you an idea what I would need:
http://www.cypress.com/psoc4ble/
The interface to the periphery is the BLE application, which if course should be user defined. For easing the job, advertising (broadcasting) would be the preferred method. Please see the reference design:
http://www.eetimes.com/document.asp?doc_id=1280914
The discussion however, what physical layer to use is still open, since zigbee has ist merits.
Similar threads
