Forum Replies Created
-
Posts
-
Sorry to hear the trouble you had to go through. Two quick comments:
1) There is actually no need to recompile osFWUpdater — it’s just a GUI for running avrdude command. You can directly run command ‘avrdude -c arduino -p m1284p -P /dev/ttyxxx -U flash:w:xxx.hex’ where /dev/ttyxxx is the serial port name, and xxx.hex is the firmware file name.
2) I am also a bit surprised that VirtualBox in Mac doesn’t work — you should be able to pass the USB device through to the virtual system, and therefore it should be fine even if the host system doesn’t have the driver for that USB device. To do so you will need to go to the VirtualBox menu -> USB devices and select the ch340g device so that it can be passed through to the virtual system.OK, I see what you mean. So looks like for you the solution is to have program-level master station — in other words, each program can associate a specific master station. As I described earlier, you can always achieve this by using a parallel (i.e. non-sequential) station as a master station. Then in each program you can set that station to run for the entire duration of the program. This way you can associate different master stations in different programs.
I guess another choice is to get 110V to 24V AC transformer (which is the type we sell), and then use a 220V to 110V step-down adapter which may be easier to source.
@pls90: can you elaborate on ‘S1 and Sx cycle between 24V and 0V every second’? Do you mean all stations turn on and off at the same time every second, or the stations run one after another every second? Also, does this only happen if you define a master station? If you don’t define a master station does the issue occur?
Which compiled application are you referring to? For OSPi or microcontroller-based OS? For OSPi, it’s better if you run the build.sh script to compile it locally, because you may have a different version of Raspbian, and the compiled version may not work on your particular Raspbian. Also, keep in mind that the firmware is cross-platform — it’s for all of OS, OSPi and OSBo (and including any Linux system). Providing compiled binaries for all platforms is time consuming and in my opinion not necessary.
Where do you get your 24VAC sprinkler valves? Won’t the supplies of the valves provide matching transformer?
Can you specify your need? It’s unclear to me exactly how you want the two master stations to work with the valves. Firmware 2.1.4 allows you to associate each valve with either, both, or neither of the master stations.
Basically to handle valves that are very far apart there are two solutions. One is to use a long extension cable to connect the main controller with the expansion board. This is suitable if you have lots of stations wired to the expansion board, allowing you to place the expansion board as close as possible to those valves. The second solution is to keep the expansion board close to the main controller, and use long wires to connect to valves. This is suitable if you just have a small number of valves connected to the expansion board.
Of course another potential solution is to get a second main controller, and use the upcoming remote station feature to have the first main controller talk to the second one. But this has more added cost.
There were a couple of requests of developing a remote expansion board with radio frequency chips. I don’t think there is sufficient demand to invest time and money on developing such a remote expansion board. Even if we did, the cost would not be much lower than getting a second main controller.
Sorry but we don’t have plan to support this, partly because the app / UI already supports multiple languages and I assume most users won’t need to look at the LCD on a day to day basis.
OSPi has an on-board 4-channel ADC (PCF8591) that you can use to read analog sensor values. Although the firmware doesn’t have built-in support to read the ADC, there are plenty of C++, Python, or command line script code you can find to read the ADC. For details, check the OSPi user manual page 7:
http://rayshobby.net/docs/ospi14_manual.pdfOSPi 1.4 Plus can work with RPi 2 and RPi 1 A+ or B+. It however, doesn’t work with RPi 1 A or B — although the pins are still compatible, they can’t fit into the enclosure and the PCB cutouts. So if you want to use OSPi 1.4 Plus with RPi 1 A or B, you will have to use a ribbon cable to make the connection.
Partly the reason we discontinued the OSPi 1.4 Standard version is the fact that RPi 1 A or B is becoming increasingly obsolete, and the form factor is different from all the newer models including A+/B+/RPi 2.
You are right that BBB has build-in analog pins so there is no need to add extra ADC chip. Other than that, the price difference also comes from the fact that OSPi is in much higher demand than OSBo.
Both versions have pinouts for all available GPIO pins. You can take a look at the user manual for details:
For ospi: http://rayshobby.net/docs/ospi14_manual.pdf
For osbo: http://rayshobby.net/docs/osbo11_manual.pdfThe firmware internally still stores the number of expansion boards. However, since that assumes each expansion board is 8 stations and our current expansion board (2.0) has 16 stations, in the past it has always created confusions to users exactly how many expansion boards they should set. Therefore we decided that the UI should show the number of stations to avoid confusion.
The controller can automatically detect the number of expansion boards (so when you plug in expansion boards the UI should show you the available number of stations). In practice, because some users may want to enable virtual (e.g. RF) stations, we still leave this option as a user-settable option.
Cool. Thanks for sharing. I had to register an account to see the picture. So I am re-posting it here for those who are curious. Hope you don’t mind 🙂
Attachments:
For controllers without rain sensor port, it’s typically to use a normally closed rain sensor connected in series on the COM (common) wire. That way, the rain sensor is normally closed, allowing valve actions; when it rains, the rain sensor becomes open circuit and disables watering. OpenSprinkler has a rain sensor port and allows software-defined rain sensor actions. The only thing you have to make sure is that the sensor should be a simple on/off switch, not an analog switch. The one that you posted: I am not sure what type of rain sensor it is.
Version 2.1 does not use CH340G — it uses a USBasp bootlaoder, and the microcontorller itself handles USB tasks in software. I’ve attached the script and bootloader file for OS 2.1. You just need to run burn12mhz.sh (make sure you change the programmer to match whatever ISP programmer you are using). The hex file is the bootloader combined with firmware 2.0.7. Once it’s uploaded, you can upload a new firmware through OpenSprinkler’s USB port without using ISP programmer.
Yes, BBB has its own version of Debian. So for BBB, you just download its Debian image, burn it to SD card. The procedure for installing the unified OpenSprinkler firmware is the same for both (and for Linux in general).
Right, I agree with you that end time should probably only be applicable to parallel stations. So if we enforce this constraint, it should solve the issue of ‘clearly define what happens when multiple stations use end time’.
If a station is set to use ‘end time’ I think it’s natural to ignore weather adjustment since it has a defined end time and not defined duration.
The instructions:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-4/
specifically mention that after running the build.sh script, it will set the program to run automatically on start-up.As Samer said, the software changes pretty rapidly and it’s time consuming for us to make a new SD card image everything the software changes. With the unified firmware, the installation is pretty simple: you just grab the Raspbian image, burn it to SD card, and follow the firmware installation instructions:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-4/
the installation should take no more than a couple of minutes.Some people have used Ethernet cable for wiring sprinkler valves. It’s not really recommended because Ethernet cable wires are pretty thin and are not suitable for running high current. However, typical sprinkler valves only draw about 250mA when activated, which is not a high amount of current. So I suppose in practice it should be fine to use Ethernet cable.
