jenkie / arduino-pedelec-controller Goto Github PK

I tried to do an English version with miles as the units as I am in the UK but my coding skills aren't that good, managed to translate the menus but I never got around to changing the math to miles I just changed the units and changed the wheel size by 0.63 to compensate. It would be a much better solution to have this integrated into the main branch as a compile option and would open it up to a lot more users.

https://github.com/geofrancis/Arduino-Pedelec-Controller/blob/b362867af142b6028e2122b7b07b4844ce74a9d9/Arduino_Pedelec_Controller/menu.cpp

Hallo Jens,

ich möchte bzw. muß momentan auch - ähnlich wie Murxer - ohne PAS-Sensor fahren (Kurbel-Abzieher paßt nicht) und noch ohne Poti (hab ich noch nicht eingebaut).

Ich habe also ebenfalls die Zeile

power_set=poti_stat/1023.0*power_max;

aus Zeile 256 nach 270 kopiert. Dabei ist mir aufgefallen, daß es statt poti_stat natürlich throttle_stat, also aus Zeile 251, heißen müßte.
Bitte korrigiere das doch im Forum und sag dem Muxer Bescheid.

Desweiteren habe ich

pedaling = true;

in die Zeile 271 gesetzt, um den PAS-Sensor zu simulieren. Es wird also immer pedaliert.

Damit habe ich folgenden Effekt:

Gasannahme funktioniert wunderbar, aber wenn das Gas weggenommen wird dann rampt die Leistung des Motors langsam ab. Es fühlt sich so an, wie wenn das Gas nur ganz langsam zurückgenommen wird.
Es ist bei Dir bestimmt nie so aufgefallen, denn wenn man aufhört zu pedalieren wird das Gas sofort weggenommen.

Wie erreiche ich es am einfachsten, daß das Gas schneller reduziert wird? Oder kann ich über ändern der Regler-Parameter erreichen, daß das Gas "direkter" wird?

Ich habe dann um die Anfahrhilfe zu testen die Zeile mit dem pedaling = true wieder herausgenommen, und ich muß sagen: tolle Sache! Funktioniert 100 pro! Jedoch (sorry, will ja nicht kleinlich sein), wenn man stoppt, dann dauert es doch lange, bis man wieder starten kann. Müssen die 3000 solange sein, oder was hat es damit auf sich? Bei Verzögerungen ist die Geschwindigkeitsanzeige etwas träge. Man beschleunigt halt auch langsamer als man verzögert! Da müsste man beim Verzögern die Geschwindigkeit schneller anpassen, als beim Beschleunigen.

Aber insgesamt ist es schon ne tolle Sache, wie der FC so funktioniert! Tolle Leistung! Ich bin begeistert! Wollt ich nochmal so sagen, nicht daß Du denkst ich kritell hier nur rum!

Hätte ich mein geforktes Projekt schon löschen können, nachdem ich den Pullrequest abgesetzt habe, um dann z.B. neu zu forken (weil mittlerweile der Master schon wieder geupdatet wurde)? Oder muß ich dann erst warten, bis entweder gemergt oder verworfen wurde?

currently the correction for the current display is done in the code.

I would be nice to have a variable in config.h instead.

Just testing github :-D

Notabschaltung und Zeitabschaltung funktioniert nicht, da FET Schalter fehlt- Abhängikeit von Revnr. einführen

wenn ich könnte würde ich es selber machen

maybe you should introduce a testing branch, where the latest changes can be tested until they are deemed stable. Similar to the Debian Linux version management.

The advantage is, that people who are downloading testing know, that the firmware might contain bugs, and there is still the fall-back to stable (or master in that case, we might want to call it stable).

That way bugs will get sorted out by a broader testing-group.

Isn't that what github is all about ;)

Thanks for thinking about it!

Hi, would it be possible to get in contact as I'm interested in your project?

Hi all, I think there is a typo in display_bafang.cpp.
Sure it shouldn't be a comparison instead of an assignment. Line 115 in the else branch.
// Search for Start Code
if(BF_ctx->RxState == RXSTATE_STARTCODE) //waiting for start code
{
if(BF_ctx->SerialPort->available())
{
BF_ctx->LastRx = millis();
BF_ctx->RxBuff[0]=BF_ctx->SerialPort->read();
if(BF_ctx->RxBuff[0]==BF_CMD_STARTREQUEST) //valid request startcode detected
{
BF_ctx->RxCnt = 1;
BF_ctx->RxState = RXSTATE_REQUEST;
}
else if(BF_ctx->RxBuff[0]==BF_CMD_STARTINFO) //valid info startcode detected
{
BF_ctx->RxCnt = 1;
BF_ctx->RxState = RXSTATE_INFO;
}
else
{
BF_ctx->RxState == RXSTATE_WAITGAP;
}
}
}

• lcd.setCursor(9,0);
  

• lcd.setCursor(8,0);

should work ok?

Das ist kein Issue, sondern ein Review Feedback/eine Frage.
Mir ist aufgefallen, dass im Code merfach ungefilterte Werte verwendet werden, insbesondere in zetkritischen Funktionen. Das halte ich fuer Problematisch -> Vorschlag: wir sollten idealerweise zwei Filterstufen haben (langsam/schnell statt einer), um in folgenden Funktionen mehr Sicherheit zu haben>
-First run check auf geladene Batterie (237)
-Leistungsberechnung (232)
-Voltage cut-off (311)
-Voltage emergency cut-off (378)
-History (394/395)
-EE Variablen (380)

Im Zweifelsfall muss die Zeitkonstante des Filters abgewartet werden, um ein einschwingen des Wertes sicher zu stellen. Diese liegt aber nach belieben tief.

when online editing, one can edit more than one file in separate browser tabs, which is convenient. What is rather annoying, that when one commits the second file, you get the message that you yourself committed a different file in the meantime, duh - I know that! And consequently you loose all your changes from file no 2 onwards.

More appropriate is downloading the files and work locally and then upload again. Hence I am using Linux, there is no client as far as I know, and I still cant get ssh to allow me in -> permission denied.

So if someone knows how to do it better, let me know.

*.ino files don't get a markup in edit mode btw.

Grüße Marc

Hallo,
ich bin durch Probleme mit meiner SW Filterung auf ein deutliches Optimierungspotential gestossen.
Hintergrund: Ich verwende die HW-SPI fuer den LTC6803 BMS Chip und habe keine Leitung mehr zum Lenker frei, um das CS am LCD zu bedienen. Daher laeuft das LCD SPI (wie bei dir) nach-wie-vor auf SW SPI.
Detail:
Die SW SPI verwendet die Arduino interne shiftOut library. Diese setzt digitalWrite() ein, um die Pins zu setzen. digitalWrite ist fuer seinen Overhead beruechtigt.
Auswirkung:
Ich benoetige 44,8ms(!) um dem Bildschirminhalt zu aktualisieren; 306ms fuer den kompletten Neuaufbau (eure Zeiten koennen variieren; ich habe den Code zu 90% auf Fixpoint umgestellt und muss fuer die Darstellung auf dem LCD daher umskalieren).
Loesung:
Anstatt shiftOut() verwende ich eine neue Funktion shiftOutFast() (Anregung und teilweise uebernahme aus http://arduino.cc/forum/index.php/topic,37304.0.html.
Ich benoetige nur noch 13,8ms um den Bildschirminhalt zu aktualisieren (Faktor 3 reduziert) und 225ms fuer den kompletten Neuaufbau.
Komischerweise spare ich, trotz der int umskalierung bei der Aktualisierung viel mehr als beim kompletten Neuaufbau. Ich kann mir das noch nicht so ganz erklaeren.

Trotzdem macht es viel aus.

Hier die Funktion (nur fuer 4bit Nokia):
//--- shiftOutFast - Shiftout method done in a faster way .. needed for tighter timer process
void shiftOutFast(unsigned char myDataPin, unsigned char myClockPin, unsigned char myDataOut) {
//=== This function shifts 8 bits out MSB first much faster than the normal shiftOut function by writing directly to the memory address for port
//--- clear data pin
bitClear(PORTC,myDataPin);

//Send each bit of the myDataOut byte MSBFIRST
for (int i=7; i>=0; i--) {
bitClear(PORTC,myClockPin);
//--- Turn data on or off based on value of bit
if ( bitRead(myDataOut,i) == 1) {
bitSet(PORTC,myDataPin);
}
else {
bitClear(PORTC,myDataPin);
}
//register shifts bits on upstroke of clock pin
bitSet(PORTC,myClockPin);
//zero the data pin after shift to prevent bleed through
bitClear(PORTC,myDataPin);
}
//stop shifting
bitClear(PORTC,myClockPin);
}