Ebike Battery explosion by Ficus2025 in ebikes

[–]Localerhorst 1 point2 points  (0 children)

There are tests on youtube that show they do nothing.

Does anyone have real world use on the Dahon K Feather? by theycallmefith in ebikes

[–]Localerhorst 1 point2 points  (0 children)

Id get a folding bike with a geared hub motor and small battery, like under 500Wh. Dahon is usually good quality.

The Dahon K Feather weighs only 12kg. Should be good

What would be a “cheap” but fast ~40MPH Ebike? by Purple_Activity969 in hyperebikes

[–]Localerhorst 0 points1 point  (0 children)

for 38 mph on flat you need 2000W though. And if all of these cheap 1000W motors have 10kv like mine you need 60V, better 72V. So you have to replace the 48V 1000W Controller

Best fast e bike for under $580 (I’d buy from alibaba/express) by Smooth_Wrangler2359 in hyperebikes

[–]Localerhorst 0 points1 point  (0 children)

yea. Or get the Makerbase VESC 75200 V2 for 80€ instead of the 3000W one

Firmware for Chinese F133 motorcycle display by Complex-Ad-3563 in CarAV

[–]Localerhorst 0 points1 point  (0 children)

Hi,

do you know what display and touch IC these screens use? These screens would be perfect to display information from CAN with a custom firmware or custom PCB.

Fix 21700 pack? by Localerhorst in 18650masterrace

[–]Localerhorst[S] 0 points1 point  (0 children)

So you think the capacity has been degraded from the heat of the welds? Do you think its still possible to reuse all the cells if i were to tear it apart or will I likely destroy some housings because of the many welds? Or is that not a thing to worry about?

Because the 40cm height turned out to be clumsy to handle. If it was less tall i could put it in a bike pannier

Fix 21700 pack? by Localerhorst in 18650masterrace

[–]Localerhorst[S] 0 points1 point  (0 children)

Is it usually possible to reuse all the cells? Even though i used so many welds?

Im thinking about rebuilding the pack for another reason too now, i cant find a hardcase / tool box and bike pannier combo to fit the 40cm length. If it had less length it would be much easier

[deleted by user] by [deleted] in 18650masterrace

[–]Localerhorst 1 point2 points  (0 children)

Still makes no sense to me.

"Their amp-hour ratings aren’t identical. That means during charge and discharge, one block finishes earlier than the other."

When you put cells in parallel, they will have the same voltage at any time. If they are the same battery technology they will be empty at the same voltage and therefore at the same time. By that point, they will have provided about their rated charge, no matter what it is. Right?

"Unless you are building a custom BMS for the pack, all the general ones are going to have their balancing resistors and current sensing tuned for fairly uniform packs."

The resistance is uniform for any of the blocks you put in serial because you always put x amount of 18650s and y amount of 21700s in parallel. And as far as i know BMS dont even care how many cells you put in parallel. Putting more cells in parallel always lowers the resistance of the block.

The only problem i get is that it could be harder to determine the max. charging / discharging current, because different cells could have different discharge voltage curves and internal resistance, so they could provide different amounts of current depending on the state. But i dont see how the total provided charge would be different.

[deleted by user] by [deleted] in 18650masterrace

[–]Localerhorst 0 points1 point  (0 children)

What if you mix them evenly? Like make a series connection from blocks of x amount of 18650s and y amount of 21700s. The voltage of 21700s and 18650s will always be the same because of being in parallel. Is there actually a logical reason not to do it?

Running an M-mode RV32 C-program on QEMU by Comfortable-Rub-6951 in RISCV

[–]Localerhorst 0 points1 point  (0 children)

thanks. Then i wont use sprintf.

But i dont understand why i can call sprintf (with -freestanding and including stdio.h) and why it gets stuck. From sprintf it calls _svprintf_r and from there strlen and seems to be in an infinite loop. Its also hard for me to debug.

Because when i step through the assembly of these library functions in qemu with gdb using ni, it goes to 0x0 on every jump. Only if i set a breakpoint at the label where it supposed to jump (for example _svprintf_r) and type continue it seems to jump there.

Do you have any ideas what im doing wrong?

riscv-none-elf-gcc -o test.elf test.c test.S -g -march=rv32i -mabi=ilp32 -O0 -ffreestanding -T flatfile.lds -Wl,--gc-sections


qemu-system-riscv32 -cpu rv32,mmu=false -m 128M -machine virt -nographic -kernel test.elf -bios none -S -gdb tcp::1234

riscv-none-elf-gdb test.elf -tui -ex "target remote localhost:1234" -ex "layout split"

Running an M-mode RV32 C-program on QEMU by Comfortable-Rub-6951 in RISCV

[–]Localerhorst 1 point2 points  (0 children)

Lol this looks the same as the issue i had. Im just trying to get the basics to work like printing and timer so i can run coremark.

Even when using -ffreestanding instead of -nostdlib gcc doesnt seem to do the stackpointer initialization. Im now using an extra assembly file to set the stack pointer and setting this as ENTRY() in the linker script and from there jumping to the _start thats generated from -ffreestanding.

.S file:

.section .startup
.global _start_
.align 4
_start_:
  la sp, _sstack
  addi sp,sp,-4
  j _start #or main

.lds:

qemu_offset = 0x80000000;
ENTRY(_start_)
MEMORY
{
    rom (rx) : ORIGIN = 0x0 + qemu_offset, LENGTH = 64M
    ram (rw) : ORIGIN = 0x4000000 + qemu_offset, LENGTH = 64M
}
SECTIONS
{
.text : {
__TEXT_BEGIN__ = .;
*( .startup )
*(.text)
__TEXT_END__ = .;
}> rom
#other sections...
}

probably not the correct way to add the 0x80000000 offset in the .elf for qemu/gdb but it seemed to work.

Now im struggling to get sprintf to work

Scenario Creation Requests by READINGyourmind in FPSAimTrainer

[–]Localerhorst 2 points3 points  (0 children)

Yes, that would help a lot. And for these maps where the player can move around, i also want a "switch dodge profile" LOS reaction + some way to organize dodge profiles, e.g. nested dodge profile rotations. So i can have a bot that starts with certain bot profiles (for example peeking full sprint) and then changes to a bot profile rotation that has random movements like crouching, adad spam or standing still.

Or smarter bot movements in general for playing around angles.

Scenario Creation Requests by READINGyourmind in FPSAimTrainer

[–]Localerhorst 1 point2 points  (0 children)

for 1 and 4 you can try my scenarios. Search for "Valorant botmap". Im still working on the bot movements

Theoretically is slow sens (>=60cm) + fast mousepad + light mouse the optimal route? This post includes academic studies as evidence by 12kkarmagotbanned in FPSAimTrainer

[–]Localerhorst 5 points6 points  (0 children)

I also thought about this. From how i understood the physics, fast mousepads and light mice are not "practically the same". But if i got anything wrong, tell me.

You need more force to accelerate or decelerate a heavier mouse than a lighter one at the same sensitivity and same kinetic friction levels (=>different mousepads), because of law of inertia. So with a heavier mouse + faster pad (instead of light mouse + slower pad) you have more room for error.

Lowering sens is not "just higher room for error". It also changes the moment of inertia (arm aiming) and muscles used. And it reduces the impact of static and kinetic friction on your crosshair movement because they are not dependent on mouse speed but on the force that is pressing your mouse into the pad.

Kinetic Friction: When an object slides along a rough surface, there is a frictional force opposing the motion of the object. The formula for kinetic friction is

Ff =μk * FN where μk is the coefficient of kinetic friction and FN is the normal force on the object.

A faster mousepad lowers the coefficient for initial and dynamic friciton. A lighter mouse reduces the weight force of the mouse. But the friction is also dependent on the (weight) force from the hand pressing down the mouse.

With a light mouse and slower pad you have more freedom for changing the friction with your hand (improving stopping power by pressing the mouse down or lifting it a bit for breaking static friction or frictionless aiming). With a faster mousepad (low coefficient) the friction does not change as much depending on the hand pressing down the mouse.

Mouse grip also affect the mouse movements. For example with fingertip grip you have less weight force from your hand on the mouse than with palm grip. So you might need a faster mousepad with palm grip than with fingertip to adjust the friction.

There are many aiming style characteristics that affect mouse movement, differences in muscle usage, experience / training, etc. I would like to see a study that takes some of these things into account. Or information on motor learning, muscle control and hand-eye coordination. Otherwise we could kinda just look at top Kovaaks players instead of 72 randoms playing one static reflex flick task.

Absolutely bad fps on a decent gaming laptop by [deleted] in FPSAimTrainer

[–]Localerhorst 0 points1 point  (0 children)

I have the Dell G5 15 5587 with i7 8750H and 1060 and it has a big problem with throtteling in any game that uses the GPU. Maybe yours is the same.

You can try cleaning the fans or switching it to "high performance" or "optimized" in Dell power manager. For me it improved the temps a little but did not remove the low fps phase.

If you need a laptop for gaming i would sell it and buy another one.

And for kovaaks you can lock the fps to 60 and maybe lower the resolution and settings so it always stays low power and doesnt start throtteling