Pages: [1] 2 3 ... 10
 1 
 on: Today at 10:40:42 am 
Started by olikraus - Last post by MarekB
Oliver, from what I read, your lib should support ILI9341 on Arduino Due. I assume that it works in HW SPI mode, right? Have you considered (or may you consider) adding Due's Extended SPI functionality? I have not found a library for ILI9431 that uses it. I am not sure how much it would speed things up but maybe it's worth a try.

 2 
 on: Today at 10:40:36 am 
Started by Onuk - Last post by surbyte
No he podido bajar la librería pero creo que tienes un problema con los pines RX TX entre el UNO y el YUN
Digo esto porque la librería habla de UNO y MEGA. Mega descartado.
EL YUN tiene un ATmega32u4 y un Atheros AR9331.
Entonces veamos la compatibilidad ATmega32u4 con el ATmega328 del UNO y que dice la librería.

Serial: 0 (RX) and 1 (TX). Used to receive (RX) and transmit (TX) TTL serial data using the ATmega32U4 hardware serial capability. Note that on the Yún, the Serial class refers to USB (CDC) communication; for TTL serial on pins 0 and 1, use the Serial1 class. The hardware serials of the ATmega32U4 and the AR9331 on the Yún are connected together and are used to communicate between the two processors. As is common in Linux systems, on the serial port of the AR9331 is exposed the console for access to the system, this means that you can access to the programs and tools offered by Linux from your sketch.

Digital pins 0 and 1 are used for serial communication between the 32U4 and the AR9331.

Entonces no puedes usar esos pines.
Vamos al Serial 1 entonces



Segun veo Serial1 es lo que debes usar? Pines 20 y 21. Debes chequear que en la biblioteca y los sketch refieran a estos pines y a Serial1..

 3 
 on: Today at 10:39:53 am 
Started by Rabenauge - Last post by Rabenauge
So. Grad eben nen paar Probefahrten in der Wildnis gemacht und- neue Erkenntnisse gesammelt.

Eine der wichtigeren: Auch Gras wird erkannt, und das zwar nun nicht zentimetergenau, aber zuverlässig. Somit sind die meisten Wegränder schonmal detektierbar. Einzelne Halme natürlich nicht-wozu auch.
Flache Hindernisse dagegen-nicht. Ich meine so Dinge wie Tischtennisballgrösse, wenn sie vor dem Auto liegen. Das Monster ist mir problemlos über den Fuss gefahren, aber immer schön am Schienbein vorbei.  smiley-cool
Das ist ok so-alles unter 5cm Höhe zählt nicht als Gegner...

Die zweite: meine Strategie kann ich _so_ komplett vergessen. Warum? Weil ich es mit arschlahmen Sensoren zu tun habe und mit ner dafür zu hohen Geschwindigkeit. Ich hab praktisch Hindernisse, die sich, sogar während der Messung, aufs Auto zu bewegen.
Allzu genaue Ergebnisse kann ich deswegen komplett vergessen. Das ist nicht schlimm-muss aber eben berücksichtigt werden.
Auch meine "Rundung" der Ergebnisse reicht da so nicht aus- am Ende kam immer was ähnliches wie ein Vollkreis heraus bei der Sache.
Und: der unwahrscheinlichste Fall (der ist im jetztigen Programm, wegen der Unwahrscheinlichkeit, erstmal überhaupt nicht berücksichtigt), dass nämlich beide Sensoren "ungefähr" die gleiche Entfernung zum Hindernis melden, tritt erstaunlich oft ein.  Hätt ich auch drauf kommen können: die Erfassungswinkel der beiden Sensoren überlappen nämlich-> das wollt ich ja auch so!
Durch die gewollte Ungenauigkeit tritt es sogar noch öfter ein (auch das hätte mir eigentlich schon einfallen müssen).
Aber interessant ist das: drinnen auf dem Teststand funktioniert es wunderbar (Murphy hat bei mir seit längerem Hausverbot   smiley )- draussen praktisch gar nicht.

Ich denke mal, zuerst werde ich das "Verunschärfen" der Sensoren-Entfernung nen bissel besser lösen (map() oder so), und dann den Fall: "beide haben dennoch das gleiche Ergebnis" behandeln, in dem dann _immer_ rechts abgebogen wird.



 


 4 
 on: Today at 10:39:46 am 
Started by banditelol - Last post by banditelol
Anyway, after a relatively long wait for answer, I realise I haven't tried everything yet, so...
I tried doing these:
  • Redownloading Arduino software (the 1.0.5 version, since I used the 1.5.x version earlier)
  • Installing newest FTDI driver for OSX
  • try to mingle with the serial port (I changed it to USBmodem one)
And after those, I tried to upload my program, and it works, yet, I don't know which one(s) solve my problem, I hope it helps

 5 
 on: Today at 10:39:05 am 
Started by srj0408 - Last post by MarkT
Is 3A enough for a GSM module?  They take large current spikes, upto 8 times the
steady transmit current as they transmit 1 timeslice in 8.

The transmit current spikes from the GSM module may simply overcome the solar
panel and cause the voltage to drop too far - unless the battery is in circuit to
buffer the pulses as has been mentioned.

 6 
 on: Today at 10:37:53 am 
Started by jasperfly - Last post by Boardburner2
Thats what he said, also said he could read no voltage present.
I would expect to read something even if its an inaccurate one.

 7 
 on: Today at 10:37:49 am 
Started by flaterik - Last post by Testato
il titolo e' bellissimo  smiley
comunque anche via transistor puoi farlo, se il blocco B consuma molto puoi usare il classico npn+rele'


 8 
 on: Today at 10:37:40 am 
Started by tom_rosenback - Last post by Costin
It was happening today twice for me...Just switchin' on the light in the room put the MC in an undefined state, all outputs were cut off...I think the internal registers were overwritten by that spike, and it requests a reset to start again...Pretty bad, becouse you can't  rely on this chip for some serious apps...

 9 
 on: Today at 10:37:06 am 
Started by gerardrev - Last post by gerardrev
Code:
data = STX+llenar+CD+fin;
digitalWrite(data);
A digitalWrite requires a pin number and a single bit value.
Yes, sorry, I've seen and you have answered before I can correct it.
Otherwise, have to go as the plot, with 0x, or without?

Code:
byte data[8];
byte STX = 0x23;
byte llenar = 0xC6;
byte CD = 0x12;
byte fin = 0x7A;

void setup() {               
pinMode(13, OUTPUT);
}

void loop() {

byte funcllenar ( byte data){
data = STX+llenar+CD+fin;
digitalWrite(13,data);
}
}

 10 
 on: Today at 10:35:38 am 
Started by bondBill - Last post by Cactusface
Hi bondBill,
                  What happens is as AWOL says the trigger pin sends out a short burst of U/S sound,  and sets the echo pin, which then goes low on receiving that burst of U/S back. What you are measuring is the time it takes that bust of U/S to hit the object and bounce back, short distance short time, long distance longer time. A bit of simple maths converts that time to distance.

I am still fairly new to Arduino and C programming, just keep reading and you will understand more, every day, if you don't take up stamp collecting.

Hope it helps, regards

Mel.

Pages: [1] 2 3 ... 10
Powered by SMF 1.1.19 | SMF © 2013, Simple Machines