yunhui
yunhui
I also run into this issue today. I am fairly surprised by this behavior. Never see this in other packages.
For reference: If we use parameters values from NEST (https://nest-simulator.readthedocs.io/en/stable/models/glif_psc.html), then `I1` and `I2` are in unit of pA, `R` is in unit of GOhm, `a`, `b`, `k1` and `k2`...
Can anyone reproduce this problem? It has been bothering me for quite a while.
> Same issue with me, MacOS Sonoma 14.1.1, Apple Silicon M1, uploading to two different ESP32 boards at 921600 fails, but 460800 works. Stumped me for a long time! @richardloxley...
> > Same issue with me, MacOS Sonoma 14.1.1, Apple Silicon M1, uploading to two different ESP32 boards at 921600 fails, but 460800 works. Stumped me for a long time!...
So we should implement our own NormalizeObservation wrapper, correct?
@shixnya Thank you for the fix! Can you also take a look at issue #337 ? The bmtk code saves the dominant_filter amplitude for the nondominant_filter, which also looks strange.
> Thanks for the report. The `rotation` mode may be fixed by sometimes before. But i will check whether the gradients is correct. This is also what I hope to...
Hi, I actually hope to know where are the gradient stored in BrainPy. For example, in PyTorch there is a `grad` field in the trained parameters which stored the gradient...
Thank you very much for the information!