Show Posts
Pages: 1 [2] 3 4 ... 10
16  Using Arduino / Project Guidance / Re: Driving Linak actuator and 4 Electric braking Castors with a Joystick on: October 17, 2013, 05:49:00 am
Only one suggestion for now.  As you just want to drive the Linak up or down with no control over speed etc., I'd suggest using a pair of 24V SPDT (automotive type) relays in an H-bridge configuration. 

e.g. Mouser 893-896H1CHCR1U2424V (these particular relays have built-in snubber resistors, you will have to add a driver transistor (NPN low-side switch is simplest) to go from the Arduino to the relay coils.

Simpler and cheaper than designing a MOSFET H-bridge for 24V, and wired up as in the attachment (clipped from a larger schematic, but should give the idea) shorts the Linak motor when not driving, hence providing braking.

Add a couple microswitches and diodes as limit switches.

Ciao,
Lenny
17  Using Arduino / General Electronics / Re: Solder possible with yellow resin around. on: October 10, 2013, 03:41:36 pm
A note for English speakers:
In Italian, and I surmise in Spanish as well, there are not separate words to distinguish between soldering and welding, so when the original poster writes "weld", English speakers should interpret this as "solder".  Ciao, Lenny
18  Maker Faire Rome - The European Edition / Makers / Re: What to see in Rome? on: September 25, 2013, 11:32:21 am
Hi Mike,

A few days ago my wife prepared a one-day walking tour of Rome for her brother who had a few-hours layover between flights.  I've attached a pdf of it.  Some of the information is probably dated, but I think it is still doable, and would give you a good sense of that glorious city. I live in Siena, but spent 4 months in Rome a number of years ago - great place to visit, but I wouldn't want to live there, especially with my daughter using a powered wheelchair.

In any case, I'd say "have fun", except that I'm sure you will do that even without my commanding it.

Ciao,
Lenny
19  Maker Faire Rome - The European Edition / Makers / Re: Translation help on: September 14, 2013, 10:22:43 am
per n. 9, la traduzione in italiano ha perso l'intento.  Alcuni trovano automaticamente buffo vedere un uomo che indossa una gonna, e Grumpy chiede se è ancora permesso ridere di questo.  Non so se il travestimeno è stato mai visto come una cosa buffa in Italia, ma una volta è stata una "shtick" abbatanza comune, specialmente in Inghilterra, meno negli Stati Uniti, ma presente anche li.  Quindi, non è solo "indossare l'abito di qualcun altro", ma qualcosa più particolare.
Ciao,
Lenni (madre lingua inglese, quindi perdonami i miei sbagli)

For Grumpy (who should correct me if I'm wrong)
For no. 9, the Italian translation has lost the sense of the original.  Some find a man dressed in a skirt automatically funny, and Grumpy is asking whether it is still (in this day of PC) permitted to laugh at this.  I don't know if cross-dressing has ever been seen as something funny in Italy, but at one time this bit of sktick was quite common, especially in England, less in the U.S. but used there as well.  Thus, the phrase doesn't just refer to "wearing someone else's clothes" which is what the Italian says, but to something rather more specific.
20  Using Arduino / Networking, Protocols, and Devices / Re: Any protocol/lib with delivery confirmation and checksum? on: September 06, 2013, 03:57:56 am
CANbus is CANbus and does not mix well with other serial protocols, and any link to an android device or bluetooth will not be by CANbus (unless you can find Android and bluetooth CAN programs and hardware).  Your original post essentially talked about robust communication, and CANbus excels at that - that's why Bosch invented it for heavy machinery and why it's become the basis of automobile systems.  BUT, it is a thing "apart". 

There is no "standard" Arduino CANbus library, and most of the libraries about are aimed at people who want to use an Arduino to read their motor vehicle's data stream, not for people who want to implement a CANbus.  Nevertheless, you can find a thread in the Due forum about developing a CAN library for the due, and a thread I started in Project Guidance, but with important contributions from several people, about a multi-node CANbus project.  I don't think that CANbus will do for you, now that you've added a bit more about what you want to accomplish, but to satisfy your own curiosity you might want to look at those threads.

Ciao,
Lenny

Ciao, Lenny
21  Using Arduino / Networking, Protocols, and Devices / Re: Any protocol/lib with delivery confirmation and checksum? on: September 05, 2013, 03:40:20 pm
The CANbus spec includes both a CRC check for integrity and an ack message for receipt.  It is a "broadcast" protocol in which the transmitting node sends a message (frame) and any node that receives it is entitled to ack it.  Whether the receiving node uses the message or not depends on what masks and filters are set, and how the MCU is programmed to use (or not use) the data.  So, data integrity is ensured.  Also, simultaneous messages or near simultaneous messages, can't conflict as there is a robust adjudication process.  Thus, you are always assured that SOME receiving module has gotten an intact message.  What you can't know without some more work is whether a particular intended recipient  has gotten it.  CAN does need some extra hardware.  On the 8-bit Arduino series, you need both a CAN controller and CAN transceiver for each node.  The Due has two CAN controllers built in, but you'd still need to add transceivers.

There is a hefty learning curve to CAN, but it is a very robust protocol.  You'll find some fairly informative CAN threads here, and lots of data sheets and application notes at the Microchip web site.  There's also a CAN forum there for when you get in trouble.

Ciao,
Lenny
22  Using Arduino / General Electronics / Re: Question about PCB service (iTead/iMall).. if anyone has experience? on: September 05, 2013, 03:20:03 pm
You can cut boards easily without blowing glass dust about by scoring with a carbide tipped laminate (i.e. Formica tm) cutting knife.  Score firmly a few times with a straight edge on both sides.  Clamp in a vice and snap apart.  If you wish, use a sharp file to smooth the edges.  Ciao, Lenny 
P.S. A plexiglass scoring knife will also work, but dulls very quickly as it's steel rather than carbide.
23  Using Arduino / Displays / Re: Refreshing/overwriting display (1.8" TFT) - flashes on: September 03, 2013, 04:11:30 am
SuperLAVA is absolutely correct with one big IF.

Specifying text background color works to remove previous text IF the new text occupies exactly the same position as the old.  If that is not the case, pixels outside that "box" will not be removed.  In my application, I am printing two horizontally centered lines of variable length.  If I overprint with longer text, OK, I could just use the two-parameter form.  If I overprint with shorter text, however, this alone will not work.

Ciao,
Lenny
24  Using Arduino / Displays / Re: ST7735 TFT LCD 1.8 inch with SD on: September 02, 2013, 06:44:56 am
I think that if you replace the Adafruit libraries that you downloaded form the github repository with the ones in the TFT\Utility folder in Arduino 1.0.5 that your problems will go away.   Ciao, Lenny
25  Using Arduino / Displays / Re: ST7735 TFT LCD 1.8 inch with SD on: August 31, 2013, 03:32:16 pm
I recently also happened to download the Adafruit libraries that are on github a few days ago (it's of course possible that they've since been changed) and I too had multiple and major compile problems.  The Adafruit libraries that are included with Arduino 1.05, however, compile and function perfectly, and can be used by themselves without using the Arduino TFT "shell" library.  If you have 1.05 look in the libraries folder, and in TFT there's a Utility folder with the Adafruit files.  BTW, the Adafruit examples that are on github work nicely with the Adafruit libraries in that Libraries\TFT\utility folder and nicely illustrate direct use of the Adafruit libraries while the TFT examples seem more limited.
Ciao,
Lenny
26  Using Arduino / Displays / Re: Refreshing/overwriting display (1.8" TFT) - flashes on: August 29, 2013, 05:07:27 am
Though it is unlikely to completely eliminate the flashing effect, I'd suggest erasing text a little differently.  

To overpaint with a rectangle you have to calculate coordinates and then, in effect, paint a series of lines.  You can remove text by changing text color to your background color and then writing the same text again.  You can, for example, put the printing routine in a Print_Or_Erase procedure to which you pass your text and a flag for "print" or "erase".  As the following sketch (snipped out of a much larger program) illustrates, doing this is a little faster (just ca. 2%) than erasing by filling a rectangle, and it may therefore be a bit less visually distracting if the print and erase don't follow each other as fast as they do in this sketch.
Code:
#include  <avr/pgmspace.h> // PROGMEM (flash) handling
#include <Adafruit_GFX.h>    // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library
#include <SPI.h>

#define cs   10
#define dc   9
#define rst  8  // you can also connect this to the Arduino reset

Adafruit_ST7735 tft = Adafruit_ST7735(cs, dc, rst);
float p = 3.1415926;

#define Landscape 3
#define Background ST7735_WHITE
#define charwidth 6 // from AdaFruit GFX
#define charheight 8 // from AdaFruit GFX

void setup(void) {
  Serial.begin(115200);
  Serial.print("hello!");

  tft.initR(INITR_BLACKTAB);   // initialize a ST7735S chip, black tab
  tft.fillScreen(Background);
  tft.setRotation (Landscape);
  int CtrX = tft.width()/2;
  int CtrY = tft.height()/2;
  byte txtsize = 2;
  tft.setTextWrap(false);
  tft.setTextSize(txtsize);
  uint32_t time = millis ();
  
  for (byte i=1; i<= 10; i++){
    tft.setTextColor(ST7735_BLACK);
    tft.setCursor(CtrX-(9*charwidth*txtsize)/2,3);
    tft.println("CONTACTOR");
    tft.setCursor(CtrX-(5*charwidth*txtsize)/2,3+charheight*txtsize);
    tft.println("FAULT");
    tft.setTextColor(Background);
    tft.setCursor(CtrX-(9*charwidth*txtsize)/2,3);
    tft.println("CONTACTOR");
    tft.setCursor(CtrX-(5*charwidth*txtsize)/2,3+charheight*txtsize);
    tft.println("FAULT");
  }
  time = millis() - time;
  Serial.print ("Elapsed time for 10 'erase by overprint' = ");
  Serial.println (time);
  Serial.println ();
  tft.setTextColor(ST7735_BLACK);
  tft.setCursor(CtrX-(9*charwidth*txtsize)/2,3);
  tft.println("PRINTOVER");
  tft.setCursor(CtrX-(4*charwidth*txtsize)/2,3+charheight*txtsize);
  tft.println("DONE");
  delay (3000);

  tft.setTextColor(Background);
  tft.setCursor(CtrX-(9*charwidth*txtsize)/2,3);
  tft.println("CONTACTOR");
  tft.setCursor(CtrX-(4*charwidth*txtsize)/2,3+charheight*txtsize);
  tft.println("DONE");
  time = millis ();
  for (byte i=1; i<= 10; i++){
    tft.setTextColor(ST7735_BLACK);
    tft.setCursor(CtrX-(9*charwidth*txtsize)/2,3);
    tft.println("CONCTACTOR");
    tft.setCursor(CtrX-(4*charwidth*txtsize)/2,3+charheight*txtsize);
    tft.println("FAULT");
    tft.fillRect (CtrX-(9*charwidth*txtsize)/2, 3, 10*charwidth*txtsize, 2*charheight*txtsize, Background);
  }
  time = millis() - time;
  Serial.print ("Elapsed time for 10 'erase by fillRect' = ");
  Serial.println (time);
  tft.setTextColor(ST7735_BLACK);
  tft.setCursor(CtrX-(8*charwidth*txtsize)/2,3);
  tft.println("fillRect");
  tft.setCursor(CtrX-(4*charwidth*txtsize)/2,3+charheight*txtsize);
  tft.println("DONE");
} // end setup

void loop() {
}
Ciao,
Lenny
27  Using Arduino / Displays / Re: TFTshield : how to RESET pin? (#define LCD_RESET A4->RST?) on: August 22, 2013, 02:01:03 pm
I think that at this point the best thing to do would be to read, line by line, the example that you are trying to run as well as the library *.cpp file.  You must understand what they are doing, or you will not get things to work correctly.  You probably CAN use pin2, if it is not being used elsewhere in the program, but you will surely have to change some #define statement(s) to do so.  Ciao, Lenny
28  Using Arduino / Displays / Re: TFTshield : how to RESET pin? (#define LCD_RESET A4->RST?) on: August 22, 2013, 09:14:58 am
The TFT reset has nothing whatsoever to do with the backlight.  The backlight is either directly powered from Vcc or from a PWM pin (depending on whether it is PWM capable, or whether that line is even brought out to where you can connect to it).  The Reset function resets the controller chip, something that has do be done during startup of the screen.  It can either be handled by a software routine in the sketch, using a digital pin for that, or as a "side effect" of hitting the Arduino's reset button, but the sketch has to correctly specify one or the other.  Even if you actually connect to the Arduino reset pin, you probably have to leave a #define for the reset function in the sketch, because the sketch will somewhere call upon that pin (even if not connected and not used) and will give you a "not defined in this scope" error if you've taken out the #define.

I don't recall whether the reset occurs when the pin goes low or high (probably low as that's the way most chip reset functions work).  So, if you've connected to pin2, the sketch (or library that it calls) has to momentarily set that pin LOW when starting up the screen.  If you define the reset as that pin in your sketch, the library should actually take care of setting it high and low as needed and you should not be setting it high.

For the moment, I'd suggest disconnecting your sensor from the pin defined as reset in the examples you are trying to run and work at getting the screen working and at understanding what's going on in those examples.  It will then be easier to make the changes needed to free up that pin, either by letting the Arduino reset button handle things, or by using a different pin for the software reset.

Ciao,
Lenny
29  Using Arduino / Programming Questions / Re: Saving parameters to flash on: August 07, 2013, 10:40:12 am
Here's an example of using two EEPROM memory rings to store two variables called Mode and AHr.  Bytes 0 and 1 are used to store the current address of the two rings, so the MCU remembers where you are between re-starts.  Those two bytes are written with a new address once every time the Arduino is started, but in my application that's no more than a few times (e.g. 10 times) a day.  Mode and Ahr get stored in their current addresses every time they change, and that's many times a day (e.g. 220 times a day), but in each new session a different address around the ring is used for this.  With a 20 byte ring, this works out to about 25 years of reliable EEPROM storage.
Code:
... defined constants
// modes as cycled by ModeSwitch
#define Drive1 1
#define Drive2 2
#define Drive3 3
#define Seat 4
#define Lights 5

... globals:
byte Mode = Drive1;
byte ModeAddress; // address in EEPROM where last Mode stored
byte AHr = 0; // half AmpHours
byte AHrAddress; // address in EEPROM where AHr is stored

... in Setup ()
  EEPROM_RING (); // set up, maintain and read ring memory to store Mode and AmpHrs

... the EEPROM_RING function that's called:
// set up ring memory for Mode
  ModeAddress = EEPROM.read (0); // address where Mode value was last stored
//  Mode EEPROM memory ring runs from address 20 through 39
  if ((ModeAddress < 20) || (ModeAddress > 39)){
    Serial.println (F("A Mode value has not yet been stored"));
    ModeAddress = 20;
  }
  else {
    Mode = EEPROM.read (ModeAddress);
    Serial.print (F("Stored Mode = "));
    Serial.print (Mode);
    Serial.print (F(" in byte "));
    Serial.print (ModeAddress);
    ModeAddress = ModeAddress + 1;
//  Mode EEPROM memory ring runs from address 20 through 39
    if (ModeAddress > 39){
      ModeAddress = 20;
    }
  }
  EEPROM.write (0, ModeAddress); // address where Mode will be stored
  EEPROM.write (ModeAddress, Mode); // re-stored in new address
  Serial.print (F("   Mode will now be stored in byte "));
  Serial.println (ModeAddress);
// set up ring memory for AmpHours
  AHrAddress = EEPROM.read (1); // address where AHr value was last stored
//  AHr EEPROM memory ring runs from address 40 through 59
  if ((AHrAddress < 40) || (AHrAddress > 59)){
    Serial.println (F("An AHr value has not yet been stored"));
    AHrAddress = 40;
  }
  else {
    AHr = EEPROM.read (AHrAddress);
    Serial.print (F("Stored AHr = "));
    Serial.print (AHr);
    Serial.print (F(" in byte "));
    Serial.print (AHrAddress);
    AHrAddress = AHrAddress + 1;
//  AHr EEPROM memory ring runs from address 40 through 59
    if (AHrAddress > 59){
      AHrAddress = 40;
    }
  }
  EEPROM.write (1, AHrAddress); // address where AHr will be stored
  EEPROM.write (AHrAddress, AHr); // re-stored in new address
  Serial.print (F("   AHr will now be stored in byte "));
  Serial.println (AHrAddress);
  int StartingVolts = READ_VOLTS ();
  if (StartingVolts > RechargeVolts){
    AHr = 0;
    EEPROM.write (AHrAddress, AHr);
    Serial.println (F("Battery has been recharged; AHr reset to 0"));
  }
} // end of EEPROM_RING
Ciao,
Lenny
30  Using Arduino / General Electronics / Re: How to connect Arduino to car electric system (12V) ? on: August 05, 2013, 05:11:02 am
I'm afraid I'm too lazy to extract the little that is relevant to your question, but the following threads contain information about using a Recom 500 mA DC-DC convertor which has a control pin in a system that goes from 24V (nominal, lead-acid batteries) to 5V and (at the end of a long process) designs for both push-button on/off control and automatic on/off control (based on CAN bus activity for that project).  Effeciency of the Recom (at Vout = 5V) is >70% for outputs over about 10 or 20 mA, and >Z=80% for 100 mA on up.  In many applications no external components are needed though (optional) input and output capacitors are recommended in some circumstances - you would probably at least want the input capacitor.  It is SMD, but the footprint matches DIP so it's easy to hand solder if you're uncomfortable wit reflow.  Ciao, Lenny
http://forum.arduino.cc/index.php?topic=168849.0
http://forum.arduino.cc/index.php?topic=171236.0
Pages: 1 [2] 3 4 ... 10