Show Posts
Pages: 1 [2] 3 4 ... 291
16  Using Arduino / Networking, Protocols, and Devices / Re: Comcast blocks port 1080 inbound on: October 05, 2014, 09:45:29 am
(just a thought) using port numbers above 32767 might reveal  implementation defects smiley-wink

Being just a subset of what the current code uses, not sure I'd expect any additional trouble.

Quote
your ephemeral port patch sounds reasonable in itself, but is no guarantee there will be no ports blocked in that range. So it does not make the algorithm more robust.

Agree no guarantee, but it may in fact be more robust as the 49152–65535 range is recommended by IANA. The history of what ranges various OS and versions have used is interesting in that it's quite varied. Recent versions of Windows use the IANA range. (This suggests a new slogan, "Arduino: No worse than Windows!"  smiley-wink )

Well maybe that last isn't such a good idea. At any rate, I've begun testing with the IANA suggested range. My one logger will take a little over 11 days to cycle through the 16K port numbers, another logger will only take a little over two days.
17  Using Arduino / Networking, Protocols, and Devices / Re: Comcast blocks port 1080 inbound on: October 05, 2014, 06:39:14 am
I do not prefer this kind of patches (hard coded) in Arduino core code.
...
does this make sense?

Yes that does make sense Rob, thanks. Winced at it a bit myself, which is why I asked.

However, this is not a section of code I'd want to introduce that much overhead (or delay) into. Further, I'm not sure it's possible to positively identify a blocked port vs. some other issue (e.g. a bad IP address) in the code.

I only know enough to be dangerous with this stuff, but in debugging the problem, I came across the concept of "ephemeral ports". I wonder if using the range 49152 to 65535 would be better* than 1024 to 65535. Not sure whether there's any downside to rotating through "only" ~16,000 ports vs. ~64,000.

* less likely to be blocked by ISPs, etc.

http://en.wikipedia.org/wiki/Ephemeral_port
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#Dynamic.2C_private_or_ephemeral_ports

PS: A patch to use the ephemeral port range:

Code:
------------------------------ EthernetClient.cpp ------------------------------
@@ -12,7 +12,7 @@ extern "C" {
 #include "EthernetServer.h"
 #include "Dns.h"
 
-uint16_t EthernetClient::_srcport = 1024;
+uint16_t EthernetClient::_srcport = 49152;      //use IANA recommended ephemeral port range
 
 EthernetClient::EthernetClient() : _sock(MAX_SOCK_NUM) {
 }
@@ -51,7 +51,7 @@ int EthernetClient::connect(IPAddress ip, uint16_t port) {
     return 0;
 
   _srcport++;
-  if (_srcport == 0) _srcport = 1024;
+  if (_srcport == 0) _srcport = 49152;
   socket(_sock, SnMR::TCP, _srcport, 0);
 
   if (!::connect(_sock, rawIPAddress(ip), port)) {
18  Using Arduino / Networking, Protocols, and Devices / Comcast blocks port 1080 inbound on: October 04, 2014, 09:25:20 pm
I recently switched to Comcast internet, and it works fine, but my Arduino IoT loggers started to experience occasional connect failures when sending data to online database services. After a week of spinning wheels, jumping to bad conclusions, barking up wrong trees, and not recognizing evidence that pointed to the actual problem, I finally realized that Comcast blocks inbound traffic on port 1080.

EthernetClient.cpp starts with port 1024, increments it for every connect, then when it rolls over from 65535 to zero, it bumps it back to 1024. When trying to use port 1080, it sends the initial SYN but nothing ever comes back, so it times out after ~30 seconds.

Here is a patch that seems to avoid the problem. Searching the forum, I was surprised that I didn't find any prior discussion of the problem, Comcast being fairly common. Is it worth submitting an issue against the Arduino repo?

Code:
@@ -48,11 +48,11 @@ int EthernetClient::connect(IPAddress ip, uint16_t port) {
   }
 
   if (_sock == MAX_SOCK_NUM)
     return 0;
 
-  _srcport++;
+  if (++_srcport == 1080) ++_srcport;         //comcast blocks port 1080 inbound, so skip it
   if (_srcport == 0) _srcport = 1024;
   socket(_sock, SnMR::TCP, _srcport, 0);
 
   if (!::connect(_sock, rawIPAddress(ip), port)) {
     _sock = MAX_SOCK_NUM;

19  Using Arduino / Motors, Mechanics, and Power / Re: Using a solenoid valve (utter newbie alert - please don't eat alive!) on: October 04, 2014, 07:07:40 pm
There was very little information for them - just basic specs like the voltage, dimensions, etc and the flow paths taken when open and closed. And googling doesn't provide any more.

Maybe the mfr. has a contact email for technical questions.

Quote
The pop was electrical. It happens each time it's plugged in. There is no mechanical motion (that being of course the goal). Is it possible that these solenoids are just defective or something?

I might also ask the mfr. about the sound. Mechanical motion may not be visible but internally the solenoid plunger should be moving or at least exerting some force. Brand-new but defective equipment is always well down my list of suspects. Possible, but not very probable.

Measuring the current drawn when energized against the mfr. spec would be one indication whether things are OK electrically.
20  Using Arduino / Motors, Mechanics, and Power / Re: Using a solenoid valve (utter newbie alert - please don't eat alive!) on: October 04, 2014, 06:57:05 pm
When I plug it in, the red light comes on, I hear an electrical pop followed by an electrical hum that sounds like  little transformer.

I'd expect to hear the solenoid operate, and a hum wouldn't be unusual while it's energized. If the "pop" is a mechanical sound rather than say, that of an electrical arc, it's probably OK.

Quote
Also, another super-basic question: Is it okay for the solenoids to be left engaged for a long period of time? Or is it important that they not be left open for more than X seconds because, say, overheating risk or something?

You need to refer to the manufacturer's information, i.e. datasheet or whatever. Surely there are solenoid valves that are rated for continuous duty, but there are probably also types that have a limited duty cycle. The manufacturer's doc should say.

I don't actually have any experience with pneumatic valves like this, but I have used similar solenoid valves for liquids. Some rely on the pressure of the working fluid to operate. The inscription on this one (1.5~8kgf/cm2) would seem to indicate a minimum pressure. I wouldn't think that operating this type of valve dry would harm anything, but without some pressure on it, it's possible that it won't appear to actually open.
21  Using Arduino / General Electronics / Re: Question about capacitors on: October 04, 2014, 02:58:36 pm
In almost all circuits I've come across using integrated circuits, it seems wise - if not necessary - to place a smallish (e.g. 0.1uF) capacitor across the Vdd/Vss pins...

This is widely accepted as a necessary practice. Hard to find a manufacturer's datasheet that does not mention it. If the circuit doesn't work, and the manufacturer's recommendations have not been followed, they wouldn't give a person the time of day and rightly so. Indeed some -- even many -- circuits may operate without bypass capacitors under certain conditions, but that most definitely does not make it acceptable. Lots of equipment is built with one or more bypass capacitors on each chip; there is a reason for this else the trouble and expense would be avoided.

Some good reading here that may clarify some of the questions you raised:
http://www.thebox.myzen.co.uk/Tutorial/De-coupling.html
22  Using Arduino / Storage / Re: Do you want Long File Names in SdFat? on: October 04, 2014, 01:02:27 pm
I haven't felt a need for LFN. If it adds significantly to processing overhead or to the code footprint, I'd prefer it be an option, I like SdFat a lot just like it is!
23  Using Arduino / Storage / Re: EEMEM on: October 04, 2014, 09:28:19 am
Code:
// A EEMEM structure or EEMEM variable is not located somewhere.

...which makes it quite memory efficient. We haven't yet figured how much data can be stored in the modestly sized EEPROM of the typical microcontroller, but current research indicates it to be well in excess of the yottabyte region  smiley-wink

Seriously, while there may be instances where one needs to know the address of data in EEPROM, often it is no more necessary than it is to know the address of a variable in SRAM. Here is a simple example using <avr/eeprom.h>.
24  Using Arduino / Project Guidance / Re: How to set a timer interrupt on: October 02, 2014, 06:48:49 pm
Good information here:
http://www.gammon.com.au/forum/?id=11504

And also here:
http://fourwalledcubicle.com/AVRArticles.php

There are also libraries to help set up timers. Usually though, it only requires a few lines of code, if you are comfortable dealing directly with the microcontroller's registers. The Atmel datasheet is also an important document to have.
25  Using Arduino / Networking, Protocols, and Devices / Re: Regarding RTc on: October 01, 2014, 06:41:57 pm
In any case, you might find the playground useful:

http://playground.arduino.cc/code/time

The Time library is not compatible with the Due. I haven't tried PJRC's improved version but am fairly certain that it would not be, either. Have a look at these:

http://forum.arduino.cc/index.php/topic,136843.0.html
http://forum.arduino.cc/index.php/topic,136126.0.html
https://github.com/MarkusLange/Arduino-Due-RTC-Library

IIRC the 1307 is a 5v-only chip, will it work with 3v3 signals?

You do recall correctly, recommended supply voltage is 4.5V min, 5.0V typical, 5.5V max.
26  Community / Bar Sport / Re: If you're ever in Johannesburg..... on: October 01, 2014, 06:33:49 pm
Haha, if the place hasn't burned to the ground!
27  Using Arduino / Project Guidance / Re: PCF2127T on: September 27, 2014, 08:31:00 pm
I dont have experience with RTC, but i need one pretty accurate (I found this IC), and where you are refering to change the library,

How accurate do you need?  DS3231/32/34 are some of the more accurate low-priced RTCs, 2ppm.
28  Community / Bar Sport / Re: Lead free solder on: September 23, 2014, 04:57:13 pm
I'm quite willing to believe the EU is a bunch of bureaucrats passing pointless directives just for the sake of it, although proof of that seems mostly anecdotal.

Happens everywhere including of course here in the US. Congress evidently thinks that because it's their job to make the laws, then the more they make, the better. Nothing could be further from the truth. They also like to make laws because then they appear to be actually doing something. But most of the activity at best is worthless; or worse, is counterproductive tampering. Oft times, doing nothing is the best thing.

Regarding lead free solder, a very good question is if it causes a higher level of failures, then what is the environmental impact of not only scrapping more electronic devices, but also of manufacturing replacements. It's a very difficult question, I don't pretend to have the answer, but I'd be surprised if it was even considered, let alone answered, before the lead-free laws were passed.

In a similar vein, the July 2013 issue of IEEE Spectrum asked, "Are Electric Cars Really Green?" This of course raised quite a controversy, but again, it's a very difficult question to answer, if the end-to-end impact is truly considered. IEEE evidently thought that it was an important enough question that it ran it as the cover story.
29  Community / Bar Sport / Re: Lead free solder on: September 23, 2014, 04:37:10 pm
I just got an architect desk lamp and LED bulbs. The bulbs are so heavy that the lamp can only stay at one position, the worst one of course. It stands tall and won't get closer to my desk without toppling over. I am in need of lead bricks.

Sorry, you can't have them, too toxic. You can only have RoHS bricks.
30  Community / Products and Services / Re: MCP79412 Real-Time Clock on: September 23, 2014, 10:12:28 am
I am interfacing Arduino due with MCP79412
I got this error , i configured MCP79412RTC lib also ....

I don’t have a Due, but after a little research, I found that the Arduino Time library is not compatible with the Due.  As you are aware, my library in turn depends on the Time library.

Please have a look at these forum threads:
http://forum.arduino.cc/index.php/topic,136843.0.html
http://forum.arduino.cc/index.php/topic,136126.0.html

And the library here:
https://github.com/MarkusLange/Arduino-Due-RTC-Library

My library relies on data types (time_t, tmElements_t) and functions defined by the Arduino Time library.  I’m afraid it would need to be rewritten to make it compatible with the Due.  Sorry about that.
Pages: 1 [2] 3 4 ... 291