tumanako-devel Mailing List for Tumanako

I studied in the master of electrothecnic and computers in Oporto,
Portugal, and for some reasons i didn't finished, but i decided do
something beyond the work with my family in the vineyards.

I saw that the Tumanako project would be good to learn.

My intentions are converte a car or a pick-up to electric, and as i'm
almost unemployed, perhaps, if i find someone to colaborate, make some
business with it.

The schematic that i implemented is one that are in the book "VAS P.,
sensorless vector and direct torque controle , Oxford university press, New
York 1998", "schematic of the rotor-flux-oriented control of a voltagem
source inverter-fed induction machine".

The motor parameters that i used i found in a papper, 22kw, 4 poles.

The PI values was with some attempts, but i'm thinking in make a genetic
algorithm to tune it. I don't see another way, i have no experience, like
Laplace.

The calculations of the rotor time constant i followed yours wiki
references. It requires some hard computation and must be implemented with
concurrency in the microcontroller. My experience with embedded control is
very little, i must learn.

The calculation of the rotor magnetisation current i followed the
"Freescale" papel and others.

I'm searching for a real cheap motor with all the parameters known.

Johannes is not much interested in the ifoc and i undertand, V/f is much
simpler and the efficiency, maybe is not much different.

Regards
Amândio Miguel
Em 19/09/2016 19:22, "Amândio Miguel Rodrigues Cordeiro" <
ama...@gm...> escreveu:

> Hi
> At several months that i see yours work and decides implement the IFOC
> algorithm and the calculation of the rotor time constant, with a simulation
> of the induction machine.
> Are you still interested in this?
> Some of the work that i did is in https://github.com/AmandioCordeiro/IMSC
> Sorry for my poor English
>
> Best regards
> Amândio Miguel Cordeiro
>

Hi Amândio

This is great work and we are very much interested in what you have done
(and your English is fine!).  Johannes has been making most development
progress recently using a slip control approach, but IFOC is still a very
good implementation to have.

Do you have plans to use this yourself in anyway? It would be good to know
your background and what created your interest in this...

Ultimately I would like to see the project to have the ability to switch
between slip control and IFOC (and possibly others) at build time.  Then we
can have test cases for power, torque and control "elegance" to compare the
approaches and evaluate them for different situations etc.

Regards
Philip


On 20 September 2016 at 06:22, Amândio Miguel Rodrigues Cordeiro <
ama...@gm...> wrote:

> Hi
> At several months that i see yours work and decides implement the IFOC
> algorithm and the calculation of the rotor time constant, with a simulation
> of the induction machine.
> Are you still interested in this?
> Some of the work that i did is in https://github.com/AmandioCordeiro/IMSC
> Sorry for my poor English
>
> Best regards
> Amândio Miguel Cordeiro
> ------------------------------------------------------------
> ------------------

Hi
At several months that i see yours work and decides implement the IFOC
algorithm and the calculation of the rotor time constant, with a simulation
of the induction machine.
Are you still interested in this?
Some of the work that i did is in https://github.com/AmandioCordeiro/IMSC
Sorry for my poor English

Best regards
Amândio Miguel Cordeiro

Hi all,

I haven't looked at the Tumanako dashboard app in a while due to being 
very busy with work and other projects. Also, I bought a Leaf, so I've 
'sold out' to the proprietary technology. However, my Leaf has some 
issues with its entertainment module. The stereo part would be easy to 
replace, but the module also shows useful vehicle data and programs the 
charge timer. Maybe one of these days I'll replace it with something 
which runs the Tumanako dashboard - I just need to hack into the Leaf 
CAN bus.


-- 
Riverhead Technology
Jeremy Cole-Baker
Ph. (+64) 27 673 0129
www.rhtech.co.nz

Hi Robin, I think that would be a great thing for you to work on.

Johannes, if you want to suggest new features you might want in an Android
dashboard (or changes in the protocol - which is designed to communicate
via bluetooth), let Robin know what you need.  Robin, talk with Jeremy if
you want an intro to the current code base.

Here is some of the existing documentation and useful starting points
(sorry about the broken images on the source forge wiki, you can still see
them if you click the links though):
http://tumanako.sourceforge.net/wiki/index.php/Dashboard
http://tumanako.sourceforge.net/wiki/index.php/STM32MCU#Bluetooth_Dashboard_Connection
http://www.rhtech.co.nz/downloads.html

Cheers
Philip



On 1 March 2016 at 04:13, Robin Vobruba <mls...@gm...> wrote:

> thanks philip (also for the fast reply)!
>
> johannes, i do not understand much but.. sounds great!!
> so you helped with (or made yourself) 30 such car conversions already??
> wish you all the best with all that, and also hope your old team gets
> together again! :-)
>
> the main reason i wrote, was to see if i could help with some minor stuff.
> as i remember you are all kind of low-level guys, mostly into electronics,
> mechanic and C coding, while i am a high-level (usually desktop software)
> Free Software developer. tell me if i could be of any help, possibly. the
> only thing i would say where i have some possibility to help, is the
> android app (the dashboard).. is that still useful for your current setup,
> johannes?
>
> 2016-02-29 12:01 GMT+01:00 <de...@jo...>:
>
> > Hi everyone,
> >
> > thanks for the reference, Philip.
> > So even though I sort of took off with my own hardware, I still consider
> > the software as part of the tumanako project and the code is also still
> > hosted in the tumanako git.
> >
> > As you might know I am happily driving around in my tumanako powered car
> > and so are about 30 more people (although most of them still seem to be
> > "driving" on their workbench only).
> >
> > So here is what I have:
> > - Working motor/vehicle control firmware
> > It uses pure slip frequency/amplitude control and achieves high motor
> > efficiency and power. My Polo uses 12kWh/100km off the wall and the
> > entire system is passively cooled. I have come to the conclusion that
> > FOC offers no advantage if a speed sensor is being used. Theres also
> > things like variable regen, cruise control etc.
> > - A web interface for configuration and monitoring
> > - A bootloader for upgrading the firmware over USART3 which does not
> > interfere with the timer outputs and only needs RX/TX wires.
> > - We are currently experimenting with synchronous motor (some Lexus
> > drivetrain) and it looks promising that we can run this motor without
> > FOC as well.
> >
> > Why am I trying to manoeuvre around FOC?
> > a) It's not exactly straight forward, quantities like Id and Iq are very
> > abstract
> > b) It needs the current sensors which slip control does not
> >
> > There have been a number of refactoring approaches, like separating
> > motor and vehicle control, using the QP framework etc. which might make
> > the software simpler and more readable.
> >
> > The firmware is on the github repo, the remaining stuff is in a zip file
> > on my web page.
> >
> > I have also registered the domain openinverter.org and was picturing a
> > wiki, a forum and some shop software to go on there. Unfortunately I am
> > lacking the time to work on all that. So if the old theme wants to
> > rejoin and put some life into the project again that would be wonderful.
> >
> > All the best from Germany,
> > Johannes
> >
> > Am 29.02.2016 um 09:53 schrieb Philip Court:
> > > Hi Robin
> > >
> > > Tumanako has been pretty static, although Tom is still providing
> updates
> > to
> > > the BMS code base on occasion.  I think the best place to go for an
> Open
> > > Source motor controller being developed in the same vein is Johannes
> > > project available here:
> > >
> > >
> >
> http://johanneshuebner.com/quickcms/index.html%3Fen_motor-inverter,8.html
> > >
> > > Regards
> > > Philip
> > >
> > > On 29 February 2016 at 21:45, Robin Vobruba <
> mls...@gm...
> > >
> > > wrote:
> > >
> > >> hello everyone! :-)
> > >> (i wrote the initial versions of the SVN-to-git transfer script for
> > >> tumanako).
> > >> ... i was wondering today, what might be the state of tumanako, so i
> > went
> > >> on a duckduckgo search, and came to the sourceforge.net page. there
> is
> > >> still the old SVN repo (i guess read only), and the last commit to the
> > git
> > >> repos was in 2013 or 2014. on the github tumanako site (which i did
> not
> > see
> > >> in my initial search, and which is not mentioned on sourceforge), i
> > found a
> > >> commit from 2015.
> > >> so my question is... how do you seethe current state of the project?
> > >> is it dormant? dead? or just a bit inactive?
> > >> also.. did you maybe move on to a new project, or can you recommend
> one
> > >> that is active now and has a similar philosophy?
> > >> al the best!
> > >> robin
> > >>
> > >
> >
> ------------------------------------------------------------------------------
> > > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > > Monitor end-to-end web transactions and take corrective actions now
> > > Troubleshoot faster and improve end-user experience. Signup Now!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > > _______________________________________________
> > > Tumanako-devel mailing list
> > > Tum...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> > >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > _______________________________________________
> > Tumanako-devel mailing list
> > Tum...@li...
> > https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> >
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>

thanks philip (also for the fast reply)!

johannes, i do not understand much but.. sounds great!!
so you helped with (or made yourself) 30 such car conversions already??
wish you all the best with all that, and also hope your old team gets
together again! :-)

the main reason i wrote, was to see if i could help with some minor stuff.
as i remember you are all kind of low-level guys, mostly into electronics,
mechanic and C coding, while i am a high-level (usually desktop software)
Free Software developer. tell me if i could be of any help, possibly. the
only thing i would say where i have some possibility to help, is the
android app (the dashboard).. is that still useful for your current setup,
johannes?

2016-02-29 12:01 GMT+01:00 <de...@jo...>:

> Hi everyone,
>
> thanks for the reference, Philip.
> So even though I sort of took off with my own hardware, I still consider
> the software as part of the tumanako project and the code is also still
> hosted in the tumanako git.
>
> As you might know I am happily driving around in my tumanako powered car
> and so are about 30 more people (although most of them still seem to be
> "driving" on their workbench only).
>
> So here is what I have:
> - Working motor/vehicle control firmware
> It uses pure slip frequency/amplitude control and achieves high motor
> efficiency and power. My Polo uses 12kWh/100km off the wall and the
> entire system is passively cooled. I have come to the conclusion that
> FOC offers no advantage if a speed sensor is being used. Theres also
> things like variable regen, cruise control etc.
> - A web interface for configuration and monitoring
> - A bootloader for upgrading the firmware over USART3 which does not
> interfere with the timer outputs and only needs RX/TX wires.
> - We are currently experimenting with synchronous motor (some Lexus
> drivetrain) and it looks promising that we can run this motor without
> FOC as well.
>
> Why am I trying to manoeuvre around FOC?
> a) It's not exactly straight forward, quantities like Id and Iq are very
> abstract
> b) It needs the current sensors which slip control does not
>
> There have been a number of refactoring approaches, like separating
> motor and vehicle control, using the QP framework etc. which might make
> the software simpler and more readable.
>
> The firmware is on the github repo, the remaining stuff is in a zip file
> on my web page.
>
> I have also registered the domain openinverter.org and was picturing a
> wiki, a forum and some shop software to go on there. Unfortunately I am
> lacking the time to work on all that. So if the old theme wants to
> rejoin and put some life into the project again that would be wonderful.
>
> All the best from Germany,
> Johannes
>
> Am 29.02.2016 um 09:53 schrieb Philip Court:
> > Hi Robin
> >
> > Tumanako has been pretty static, although Tom is still providing updates
> to
> > the BMS code base on occasion.  I think the best place to go for an Open
> > Source motor controller being developed in the same vein is Johannes
> > project available here:
> >
> >
> http://johanneshuebner.com/quickcms/index.html%3Fen_motor-inverter,8.html
> >
> > Regards
> > Philip
> >
> > On 29 February 2016 at 21:45, Robin Vobruba <mls...@gm...
> >
> > wrote:
> >
> >> hello everyone! :-)
> >> (i wrote the initial versions of the SVN-to-git transfer script for
> >> tumanako).
> >> ... i was wondering today, what might be the state of tumanako, so i
> went
> >> on a duckduckgo search, and came to the sourceforge.net page. there is
> >> still the old SVN repo (i guess read only), and the last commit to the
> git
> >> repos was in 2013 or 2014. on the github tumanako site (which i did not
> see
> >> in my initial search, and which is not mentioned on sourceforge), i
> found a
> >> commit from 2015.
> >> so my question is... how do you seethe current state of the project?
> >> is it dormant? dead? or just a bit inactive?
> >> also.. did you maybe move on to a new project, or can you recommend one
> >> that is active now and has a similar philosophy?
> >> al the best!
> >> robin
> >>
> >
> ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > _______________________________________________
> > Tumanako-devel mailing list
> > Tum...@li...
> > https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> >
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>

Hi everyone,

thanks for the reference, Philip.
So even though I sort of took off with my own hardware, I still consider
the software as part of the tumanako project and the code is also still
hosted in the tumanako git.

As you might know I am happily driving around in my tumanako powered car
and so are about 30 more people (although most of them still seem to be
"driving" on their workbench only).

So here is what I have:
- Working motor/vehicle control firmware
It uses pure slip frequency/amplitude control and achieves high motor
efficiency and power. My Polo uses 12kWh/100km off the wall and the
entire system is passively cooled. I have come to the conclusion that
FOC offers no advantage if a speed sensor is being used. Theres also
things like variable regen, cruise control etc.
- A web interface for configuration and monitoring
- A bootloader for upgrading the firmware over USART3 which does not
interfere with the timer outputs and only needs RX/TX wires.
- We are currently experimenting with synchronous motor (some Lexus
drivetrain) and it looks promising that we can run this motor without
FOC as well.

Why am I trying to manoeuvre around FOC?
a) It's not exactly straight forward, quantities like Id and Iq are very
abstract
b) It needs the current sensors which slip control does not

There have been a number of refactoring approaches, like separating
motor and vehicle control, using the QP framework etc. which might make
the software simpler and more readable.

The firmware is on the github repo, the remaining stuff is in a zip file
on my web page.

I have also registered the domain openinverter.org and was picturing a
wiki, a forum and some shop software to go on there. Unfortunately I am
lacking the time to work on all that. So if the old theme wants to
rejoin and put some life into the project again that would be wonderful.

All the best from Germany,
Johannes

Am 29.02.2016 um 09:53 schrieb Philip Court:
> Hi Robin
> 
> Tumanako has been pretty static, although Tom is still providing updates to
> the BMS code base on occasion.  I think the best place to go for an Open
> Source motor controller being developed in the same vein is Johannes
> project available here:
> 
> http://johanneshuebner.com/quickcms/index.html%3Fen_motor-inverter,8.html
> 
> Regards
> Philip
> 
> On 29 February 2016 at 21:45, Robin Vobruba <mls...@gm...>
> wrote:
> 
>> hello everyone! :-)
>> (i wrote the initial versions of the SVN-to-git transfer script for
>> tumanako).
>> ... i was wondering today, what might be the state of tumanako, so i went
>> on a duckduckgo search, and came to the sourceforge.net page. there is
>> still the old SVN repo (i guess read only), and the last commit to the git
>> repos was in 2013 or 2014. on the github tumanako site (which i did not see
>> in my initial search, and which is not mentioned on sourceforge), i found a
>> commit from 2015.
>> so my question is... how do you seethe current state of the project?
>> is it dormant? dead? or just a bit inactive?
>> also.. did you maybe move on to a new project, or can you recommend one
>> that is active now and has a similar philosophy?
>> al the best!
>> robin
>>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> 

Hi Robin

Tumanako has been pretty static, although Tom is still providing updates to
the BMS code base on occasion.  I think the best place to go for an Open
Source motor controller being developed in the same vein is Johannes
project available here:

http://johanneshuebner.com/quickcms/index.html%3Fen_motor-inverter,8.html

Regards
Philip

On 29 February 2016 at 21:45, Robin Vobruba <mls...@gm...>
wrote:

> hello everyone! :-)
> (i wrote the initial versions of the SVN-to-git transfer script for
> tumanako).
> ... i was wondering today, what might be the state of tumanako, so i went
> on a duckduckgo search, and came to the sourceforge.net page. there is
> still the old SVN repo (i guess read only), and the last commit to the git
> repos was in 2013 or 2014. on the github tumanako site (which i did not see
> in my initial search, and which is not mentioned on sourceforge), i found a
> commit from 2015.
> so my question is... how do you seethe current state of the project?
> is it dormant? dead? or just a bit inactive?
> also.. did you maybe move on to a new project, or can you recommend one
> that is active now and has a similar philosophy?
> al the best!
> robin
>

hello everyone! :-)
(i wrote the initial versions of the SVN-to-git transfer script for
tumanako).
... i was wondering today, what might be the state of tumanako, so i went
on a duckduckgo search, and came to the sourceforge.net page. there is
still the old SVN repo (i guess read only), and the last commit to the git
repos was in 2013 or 2014. on the github tumanako site (which i did not see
in my initial search, and which is not mentioned on sourceforge), i found a
commit from 2015.
so my question is... how do you seethe current state of the project?
is it dormant? dead? or just a bit inactive?
also.. did you maybe move on to a new project, or can you recommend one
that is active now and has a similar philosophy?
al the best!
robin

The wiki is back!  Thanks Jeremy :)

http://tumanako.sourceforge.net/wiki/index.php/Main_Page

FYI - the original wiki disappeared when Sourceforge retired hosted apps (
https://sourceforge.net/p/forge/community-docs/Migrating%20MediaWiki%20from%20Hosted%20Apps
).

Cheers
Philip

Hi Robin,

I made a couple of changes to your svn-git migration script. I added 
support for setting the remote to sourceforge's git server and I stopped 
deleting .sch files. .sch files are the schematics for the various 
circuits in the tumanako project. These are edited with kicad and are 
the primary source files for the schematic and do belong in SCM (they're 
text files too which even makes diffing somewhat possible).

See the attached patch.

Thank you for your work, migrating to git was easy using the script.

A little while ago I upgraded the tumanako sourceforge project to the 
new Alura sourceforge platform. We were very worried that the hosted 
apps that hold the wiki and blog would be deleted during this process, 
but so far this hasn't happened.

What did happen was the old svn repository was made read-only and a new 
svn repository was created. I have made that new svn repository 
read-only as well and will delete it soon because we are moving to git.

Robin made a nice script to do the move and we decided to stick with 
sourceforge so we have combined administration of wiki and mailing list 
and SCM. I've created git repositories on sourceforge:

https://sourceforge.net/p/tumanako/_list/git

These are similar to the repositories that robin made on github. The 
qpcpp and libopencm3 repositories are pushed from a clone of the github 
repos. The rest are the result of running the migration using a slightly 
updated version of Robin's script (patch coming shortly). I have not 
migrated the changes robin made to the dashboard from github to 
sourceforge, Jeremy, if you want those changes, please migrated them 
from github.

Please verify that your code still works. The inverter firmware is 
almost certainly broken by being moved around. There may be a way to 
make it work again using the git equivalent of svn externals or the may 
be another better way of fixing it. Right now with noone linking to the 
new git repositories we have huge scope to refactor the inverter 
firmware. If any of the decisions made while splitting the firmware into 
different git repositories turn out to be inappropriate, they are easy 
to fix by re-doing the migration from svn. There may be other ways to 
change those decisions using git tools as well.

I also vote "yes" (nod), for the same reasons. 


________________________________
 From: Philip Court <ph...@gr...>
To: Tumanako General Development <tum...@li...> 
Sent: Saturday, 27 April 2013 9:39 PM
Subject: Re: Sourceforge Upgrade
 

On 27 April 2013 16:41, Tom Parker <to...@ca...> wrote:

> Should we take a vote on where to put the git repos?
>
> I vote to use the sourceforge git if only because this keeps everything
> together. Does anyone have another opinion?
>

Yep, I'm happy with that.
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Tumanako-devel mailing list
Tum...@li...
https://lists.sourceforge.net/lists/listinfo/tumanako-devel

On 27 April 2013 16:41, Tom Parker <to...@ca...> wrote:

> Should we take a vote on where to put the git repos?
>
> I vote to use the sourceforge git if only because this keeps everything
> together. Does anyone have another opinion?
>

Yep, I'm happy with that.

On 16/04/13 22:25, Tom Parker wrote:
> On 16/04/13 22:16, Philip Court wrote:
>> If there are no objections, rather than waiting for sourceforge to
>> do it for us at some point in time, I think we should push the sourceforge
>> conversion button and see what happens!
>
> I can press it later on this week.

Well, I pressed it. So far the wiki is still working at the old location.

Should we take a vote on where to put the git repos?

I vote to use the sourceforge git if only because this keeps everything 
together. Does anyone have another opinion?

Just got this in the mail from Linear Technologies
Might be interesting: 
http://cds.linear.com/docs/en/lt-journal/LTJournal-V23N1-01-df-LTC3300-1-Drew.pdf

One chip can balance up to 6 cells. Multiple chips can be put in series 
for larger packs. They mention packs of 100 cells for electric vehicles 
specifically in the document.

Bert

Am 22.04.2013 21:48, schrieb Bernard Mentink:
> Hi Johannes,
>
> The QP version "should" be able to drive a car right now. I have tested all
> functionality on the bench, just havn't quite got there running in my car ..
> (I am just finishing off wiring ... the engineering stuff has taken a long
> time .... ;-)
>
> I may have some time to try and merge the two ... but not sure on what
> the benefit would be if my ported of sine works well in the car as it is?
> Would be good if you could have a look at what I have included and compare
> to your version ..
I'll take a look as well. Its probably about removing the vehicle 
control stuff from the sine code and using some of the new libraries 
I've written from within QP.
>
> By The way, what shaft encoder are you using, I am having trouble getting
> hold of one with a long enough MTBF number ....
>
MTBF? Looks like you're doing more careful engineering than I am... I 
use this
http://www.johanneshuebner.com/coppermine/displayimage.php?album=60&pos=9
that
http://www.johanneshuebner.com/coppermine/displayimage.php?album=60&pos=16
and that
http://www.johanneshuebner.com/coppermine/displayimage.php?album=60&pos=21

Its a 2EUR fork 
<http://dict.leo.org/ende/?lang=de&search=gabellichtschranke#/search=fork&searchLoc=0&resultOrder=basic&multiwordShowSingle=on> 
light 
<http://dict.leo.org/ende/?lang=de&search=gabellichtschranke#/search=light&searchLoc=0&resultOrder=basic&multiwordShowSingle=on> 
barrier 
<http://dict.leo.org/ende/?lang=de&search=gabellichtschranke#/search=barrier&searchLoc=0&resultOrder=basic&multiwordShowSingle=on> 
CNY37. It doesn't generate a direction signal but apart from that works 
well.

/Johannes

Hi Johannes,

The QP version "should" be able to drive a car right now. I have tested all
functionality on the bench, just havn't quite got there running in my car ..
(I am just finishing off wiring ... the engineering stuff has taken a long
time .... ;-)

I may have some time to try and merge the two ... but not sure on what
the benefit would be if my ported of sine works well in the car as it is?
Would be good if you could have a look at what I have included and compare
to your version ..

By The way, what shaft encoder are you using, I am having trouble getting
hold of one with a long enough MTBF number ....

Cheers,
Bernie


On Tue, Apr 23, 2013 at 7:33 AM, Johannes Hübner <j...@jo...>wrote:

> Hi Bernard,
>
> I'm running the software checked in as "sine". Is the QP version
> actually able to drive a car right now? I think its getting time to
> merge these two versions. Any volunteers?
> As a side note, I don't have a precharge delay but a lower voltage
> limit. So say my pack voltage is 500V then I set the limit to 460V as to
> close the main contactor when the precharge has run up AND the start
> input is active.
>
> /Johannes
>
> Am 22.04.2013 20:59, schrieb Bernard Mentink:
> > Hi Johannes,
> >
> > Most of those "requests" you mentioned are incorporated in the QP version
> > of the code (i.e you can't start with throttle pressed, and the
> pre-charge
> > delays are done in software)
> > What code base are you running?
> >
> > Cheers,
> > Bernie
> >
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>

Hi Bernard,

I'm running the software checked in as "sine". Is the QP version 
actually able to drive a car right now? I think its getting time to 
merge these two versions. Any volunteers?
As a side note, I don't have a precharge delay but a lower voltage 
limit. So say my pack voltage is 500V then I set the limit to 460V as to 
close the main contactor when the precharge has run up AND the start 
input is active.

/Johannes

Am 22.04.2013 20:59, schrieb Bernard Mentink:
> Hi Johannes,
>
> Most of those "requests" you mentioned are incorporated in the QP version
> of the code (i.e you can't start with throttle pressed, and the pre-charge
> delays are done in software)
> What code base are you running?
>
> Cheers,
> Bernie
>

Hi Johannes,

Most of those "requests" you mentioned are incorporated in the QP version
of the code (i.e you can't start with throttle pressed, and the pre-charge
delays are done in software)
What code base are you running?

Cheers,
Bernie



On Mon, Apr 22, 2013 at 11:43 PM, Johannes Hübner <j...@jo...>wrote:

> Hi all,
>
> I'm am currently build a VW polo EV with the tumanako inverter of
> course. I have taken it on a few test drives and am still delighted by
> the performance of the simple slip control. It can do slight hill starts
> in 5th gear. Though I cannot compare it to FOC. The motor I use is rated
> 18,5 kW@120Hz.
>
> While driving was all smooth, there were a couple of observations that
> should be reflected in the software:
>
> - When the throttle is pressed or stuck and the inverter is started, the
> following happens:
>    - PWM is activated and generates a sine wave
>    - With the mechanical delay, the DC contactor closes
>    -> Contactor welds closed,it is not designed to switch loads.
>    -> There must be a delay between closing the contactor and starting
> the PWM
>    -> Maybe the start should be inhibited when the throttle > 0.
> - The other way around seems ok. If the inverter shuts down due to an
> error, the PWM is stopped and the contactor is opened. Due to the
> mechanical delay it does not weld closed. But maybe its advisable to
> insert an actual delay as well
> - When manually started (i.e. using the command console) the inverter is
> started but the contactor isn't closed. The precharge relay stays closed
> though. High current through the precharge resistor occurs and it
> overheats and fails.
>    -> Pay more attention to that stuff...
>
> I have also made some good observations:
> - Most vehicle signals are ground-switched, so using open collector
> outputs is perfectly sane.
> - I use the key switch for the actual power to the inverter. Saves an
> input and theres absolutely no current draw when ignition is off.
> -  For the 840µF bus capacitor in my inverter an 11W, 120R precharge
> resistor is sufficient. No heat sink required. It charges the caps from
> 0 to 480V in around a second. Also tried 5W, but that died after a
> handful of precharges.
>
> I will add low voltage, high voltage, temperature and BMS throttling
> next. Probably just linear derating curves that affect the maximum
> acceptable throttle input.
>
> Cheers,
> Johannes
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>

Hi all,

I'm am currently build a VW polo EV with the tumanako inverter of 
course. I have taken it on a few test drives and am still delighted by 
the performance of the simple slip control. It can do slight hill starts 
in 5th gear. Though I cannot compare it to FOC. The motor I use is rated 
18,5 kW@120Hz.

While driving was all smooth, there were a couple of observations that 
should be reflected in the software:

- When the throttle is pressed or stuck and the inverter is started, the 
following happens:
   - PWM is activated and generates a sine wave
   - With the mechanical delay, the DC contactor closes
   -> Contactor welds closed,it is not designed to switch loads.
   -> There must be a delay between closing the contactor and starting 
the PWM
   -> Maybe the start should be inhibited when the throttle > 0.
- The other way around seems ok. If the inverter shuts down due to an 
error, the PWM is stopped and the contactor is opened. Due to the 
mechanical delay it does not weld closed. But maybe its advisable to 
insert an actual delay as well
- When manually started (i.e. using the command console) the inverter is 
started but the contactor isn't closed. The precharge relay stays closed 
though. High current through the precharge resistor occurs and it 
overheats and fails.
   -> Pay more attention to that stuff...

I have also made some good observations:
- Most vehicle signals are ground-switched, so using open collector 
outputs is perfectly sane.
- I use the key switch for the actual power to the inverter. Saves an 
input and theres absolutely no current draw when ignition is off.
-  For the 840µF bus capacitor in my inverter an 11W, 120R precharge 
resistor is sufficient. No heat sink required. It charges the caps from 
0 to 480V in around a second. Also tried 5W, but that died after a 
handful of precharges.

I will add low voltage, high voltage, temperature and BMS throttling 
next. Probably just linear derating curves that affect the maximum 
acceptable throttle input.

Cheers,
Johannes

Hi Robin,

I haven't done much software-wise since I got a new donor car and spend 
a lot of time installing components in it.

foc.c/h in the lib-dir because the module is hardware and 
project-independent. It is only used by the foc firmware though.

Don't worry about the subfolders and the Makefile in lib. It's indeed 
just left-overs of experiments that I forgot to remove.

/Johannes

Am 22.04.2013 08:56, schrieb Robin Vobruba:
> hey... sorry for the long delay!
> have there been any advances on your side?
> i now had a look at it again, and have some more questions:
>
> - why are foc.h and foc.cpp in lib. are they also used by sine?
> - do you actually use the Makefile in lib/ ? (it seems to come from the
> libopenstm32 project)
> - in the src/ folder of the repo tuamanako-inverter-fw-motorControl,
> there are other sources (partly in sub-folder), other then sine/. what
> are these used for? are they actually separate projects?
>
> with my current, very limited view of it, i think of this ways to solve
> the issue:
> putting lib/ into a separate project called something like
> motorControl-common, and compiling it into a static lib, is the most..
> natural way of doign it. it can be compiled separately for each
> motorControl implementation, using different #define's.
> most likely, we would then use the common repo as a git sub-module in
> the sine/ and foc/ repos.
> what about the other sources currently in the repo, but not in hte sine/
> folder?
>

hey... sorry for the long delay!
have there been any advances on your side?
i now had a look at it again, and have some more questions:

- why are foc.h and foc.cpp in lib. are they also used by sine?
- do you actually use the Makefile in lib/ ? (it seems to come from the
libopenstm32 project)
- in the src/ folder of the repo tuamanako-inverter-fw-motorControl,
there are other sources (partly in sub-folder), other then sine/. what
are these used for? are they actually separate projects?

with my current, very limited view of it, i think of this ways to solve
the issue:
putting lib/ into a separate project called something like
motorControl-common, and compiling it into a static lib, is the most..
natural way of doign it. it can be compiled separately for each
motorControl implementation, using different #define's.
most likely, we would then use the common repo as a git sub-module in
the sine/ and foc/ repos.
what about the other sources currently in the repo, but not in hte sine/
folder?

On 02.04.2013 20:01, Johannes Hübner wrote:
> Am 01.04.2013 23:19, schrieb Robin Vobruba:
>> i can do that, but i think i need some more info.
>>
>> the archive contains the lib and the foc folder, but not the sine one.
>> where is the latest version of that one?
> The sine project is already in the git repo and contains all the files 
> in lib. So if it somehow uses the files in lib, they can be deleted from 
> the sine project.
> https://github.com/tumanako/tumanako-inverter-fw-motorControl/tree/master/src/sine
> 
>>
>> what do you mean with 'more meaningful renaming'? the folders? (foc &
>> lib), or the source file names?
>> i guess, you mean the lib folder. but i also think, you would be best to
>> choose a more meaningful name.
> Yeah, just the lib folder. Still can't think of anything more meaningful 
> yet since the contents is very "miscellanious".
>>
>> do both sine and foc use all the files from lib?
> Almost, about 90% share ratio
>>
>> could it make sense to actually make the stuff in lib a separate
>> library, static of dynamic, against which the other two projects link?
>>
>>
> Some files, like the params.c, contain static tables that are build from 
> a project-dependend #define. The macro-magic for this is hidden in the 
> module.  All others could indeed be built as a static library. I can 
> create a list of actually static files if you want.
> 
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire 
> the most talented Cisco Certified professionals. Visit the 
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> 

On 16/04/13 22:16, Philip Court wrote:
> I would like to retain mediawiki as the tool for documenting the project.
>   If the sourceforge conversion project does anything useful with our
> existing mediawiki that would be nice (if not, I suspect the best thing
> would be to setup a basic mediawiki in the sourceforge provided hosting).

Anyone know if it is possible to have real urls from our own domain 
using the sourceforge hosting?

> I expect the best overall setup is to have our project documentation and
> historical svn repository on sourceforge, with the new git repository on
> github.

What benefits do you see splitting the git repo off onto github?

> If there are no objections, rather than waiting for sourceforge to
> do it for us at some point in time, I think we should push the sourceforge
> conversion button and see what happens!

I can press it later on this week.

On 10 April 2013 21:57, Tom Parker <to...@ca...> wrote:

> On 01/04/13 15:02, Tom Parker wrote:
> > Some of you may be aware that sourceforge are threatening to turn off
> > our hosted mediawiki instance and upgrade the project to their new
> > platform.
>
> I got an email saying they're going to start this on active projects on
> the 22nd of April (they've been doing dead projects for a while). They
> don't know how quickly the conversions will go, but it would seem like
> we should at least have an idea of where we want to go before it happens.
>
> Does anyone have an opinion?


I would like to retain mediawiki as the tool for documenting the project.
 If the sourceforge conversion project does anything useful with our
existing mediawiki that would be nice (if not, I suspect the best thing
would be to setup a basic mediawiki in the sourceforge provided hosting).

I expect the best overall setup is to have our project documentation and
historical svn repository on sourceforge, with the new git repository on
github.  If there are no objections, rather than waiting for sourceforge to
do it for us at some point in time, I think we should push the sourceforge
conversion button and see what happens!

Cheers
Philip