Forum Replies Created
-
AuthorPosts
-
RayKeymasterYes, this would work on both the fully assembled and DIY versions. On both versions, the spare GPIO pins are available at the top of the circuit board. Of course for the DIY version you will see those while assembling the controller; for the fully assembled, you can open the enclosure (there are four screws at the back of the enclosure) and check the circuit board.
November 24, 2014 at 5:42 pm in reply to: [patch] Use the whole allocated buff for network transfers #34817
RayKeymaster@ianf: thanks for the patches. I am currently traveling out of town, but I did bring a set of OpenSprinkler so I can try the patch as soon as possible. I was under the impression that each packet in the file stream function must be 512 bytes or less, but this was probably a wrong impression. Thanks for the discovery.
RayKeymasterYes, built-in WiFi is always on our todo list. But keep in mind that having built-in WiFi will probably raise the price by $40-50 due to the hardware and development costs. Currently using an external WiFi adapter is still a cost-effective solution. The TP-link WIFi adapter that we recommend is less than $20; and if WiFi signal is an issue, you can use the TP-link Powerline adapter, which is about $30 and requires no configuration at all.
RayKeymasterAlso, note that there is a power switch on OpenSprinkler. You can simply switch it off.
RayKeymasterSorry, just realized I haven’t relied to this post. To answer your question, unfortunately I don’t have a copy of the case design files — the case is designed by SeeedStudio and they contracted it to a Chinese company to have the cases manufactured. Given that there is plenty of space close to the top of the PCB, you should be able to easily fit an nRF24 module there. If you want to use nRF24 with antenna, all you need to do is to drill a hole on the enclosure to let the antenna pass through.
RayKeymasterThis may have to do with the way the OSPi source code sends data to the shift register. In the microcontroller-based OpenSprinkler, the firmware always sends padding of 0’s so stations on the expansion boards will not be accidentally activated.
When you say ‘with expansion baord running on your breadboard’, what do you mean? Do you have a fully assembled expansion board bought from us or did you build one on the breadboard yourself?
RayKeymaster1) Yes I am aware of the recent update on the EtherCard library. The fix has been integrated to the current firmware 2.1.1 code:
https://github.com/OpenSprinkler/OpenSprinklerGen2/blob/master/enc28j60.cpp
which will be released soon.This explained the few cases I’ve seen before that the controller locks up after some amount of time. The good thing is that the firmware uses a watchdog timer to restart the controller if wdt_reset is not called in the inner loop after a couple of minutes.
2) Thanks for the change to the icon. I will check it out and integrate it.
RayKeymasterIt’s unclear to me what’s causing the issue. You said the /jp page doesn’t return, I am wondering if this might be a buffer overflow problem. If so, the most likely cause is the name of your second program, which is 12 characters long. My suggestion is to shorten that program name to 11 characters or less and see if the issue still exists.
Also, does this happen at regular intervals, like every 12 hours, or is it more random?
RayKeymaster@Andrew: I just want to briefly mention that the first support for using OpenSprinkler to control radio frequency (RF) wireless power socket has been added to the upcoming firmware 2.1.1. I’ve recently released the RFtoy gadget:
http://rayshobby.net/?p=9938
part of the purpose of this gadget is for users to easily obtain the wireless control code of these power sockets, then OpenSprinkler can simulate the remote to turn on / off these sockets.Note that RF wireless sockets (typically 433MHz) are different from WiFi power sockets in that they are not WiFi based. On the plus side, RF sockets are much cheaper and widely available.
RayKeymasterGood to hear that it’s finally working.
As to buttons: this depends on which firmware your controller is currently running. Firmware 2.1.0 uses B1 to display OpenSprinkler’s IP, B2 to display router’s IP; pressing B1 during power-on goes to factory reset, pressing B2 during power-on does nothing. Prior to firmware 2.1.0, pressing B1 during power-on goes to self-test, pressing B2 during power-on goes to factory reset.
RayKeymasterPlease check the OSBo user manual:
http://rayshobby.net/docs/osbo11_manual.pdf
page 9, BBB pin uses.
RayKeymaster1. Please make sure you are using the latest instructions and download link here;
https://opensprinkler.freshdesk.com/support/solutions/articles/5000381694-update-opensprinkler-firmware-with-downloads-2. Do not double click the executable while it’s still in the zip file. You must unzip the entire folder to your local disk, for example, desktop, and then double click the executable from the unzipped folder.
3. The instructions page has a video. If you encounter any trouble, please follow the video. Thanks.
RayKeymasterOK, assuming you mean VIN-GND is 5.1V and VCC-GND is 3.29V, the voltage reading is correct. So you can go ahead.
RayKeymasterYes, 4.56kohm is about right. Here is my suggestion:
1) plug in a USB cable to the USB port, measure VIN-GND voltage and VCC-GND voltage, they should be about 5V and 3.3V respectively. The 5V may have some variations since USB power is often around 4.6 to 4.9V. So anything in that range should be fine.
2) if step 1) passes, then unplug USB, go ahead and plug in your sprinkler transformer to the orange terminal and test voltage again.The reason I would suggest step 1 in your case is to make sure everything from the 5V to 3.3V conversion is working fine. Because USB power is internally protected, you don’t have to worry about burning anything. Once that voltage test passes, if something goes wrong in step 2, then it must be a problem with the 24V AC to 5V conversion. So this can help isolate the problem.
RayKeymasterThe soldering quality is decent. After checking all the VIN traces, the only thing I can identify is the relay’s upper-middle pin (close to the top edge of the PCB), there seems to be a solder ball that touches the nearby trace. Normally this isn’t a problem, since the traces are all covered by solder mask, however, sometimes the very edge of the trace may have copper exposed, so if you have a solder ball touching it, this may lead to shorting. I suggest using your soldering iron to reflow the relay solder joints, and re-check the VIN-GND resistance. If you still can’t figure out, send an email to [email protected] and we can see what we can do to help.
RayKeymasterVery nice. May I ask which box / brand you are using?
RayKeymasterResistance Vin to Gnd approx 126 Ohms
This is an issue: the VIN to GND resistance is too low. The instructions clearly that ‘The resistance should be at least several kilo-ohms. If either resistance is below one kilo-ohm, there is probably a shorting or solder bridge somewhere.’
It’s going to be a bit tricky to find out the issue. But to start, I’d ask you to post pictures of the front and back of the PCB (without LCD), and either post them here or send to [email protected]. Take the pictures under good lighting conditions and high resolution. Thanks.
RayKeymasterCool. Thanks for sharing. Nice box with cutout for LCD.
RayKeymasterNo problem. You helped us discover a bug, so many thanks to you.
November 11, 2014 at 12:39 am in reply to: problems on first regularly scheduled programs after FW 2.1.0 update #34604
RayKeymasterJust a quick update: I have found the cause of the issue: the logging function checks if the LOGS subfolder exists, and if so, it will attempt to create that subfolder. However, because the firmware is already using quite a lot of RAM (the microcontroller only has 4KB RAM), occasionally creating the subfolder exceeds the RAM limit, causing the controller to restart and not finishing the schedule.
I’ve adjusted some buffer sizes, and also pulled the subfolder checking and creation function out of the logging function, and the issue seems to have been resolved. The fix will be included in the next firmware update, which we are targeting to release this week. Thanks for your patience.
RayKeymasterThis will have to be a firmware fix. We will be releasing an updated firmware very soon. Thanks.
RayKeymasterYes, I’ve found the bug in the firmware that leads to the port number and will be releasing an update very soon. Thanks.
RayKeymasterIt has been brought up in another thread that when OpenSprinkler’s port number is not 80, the query to weather script will fail, and I realized this will affect the time zone query as well because the time zone query uses the same script. I didn’t think it’s related to your case, because you said you performed a reset of the controller, so the port number must be reset to 80. Just to bring this up in case it’s relevant.
RayKeymasterI can confirm that when http port number is changed, the firmware stops receiving weather data. This is due to a bug that uses the controller’s port number when sending query to weather.opensprinkler.com, causing the query to fail. A fix will be provided as soon as possible. In the meantime, please keep OpenSprinkler’s port to the default 80, and as I said for port forwarding the external port number can be a different number. Thanks.
RayKeymasterOK, that’s an interesting discovery — I had not thought about changing the port number would affect the weather script. I will check this tomorrow.
For port forwarding: external port number does not have to match the device port number. For example, you can tell the router to map external port 8080 to OpenSprinkler’s port 80. So when you are out of your home network, use http://wan_ip:8080 and the router will map that to http://os_ip:80
-
AuthorPosts